Disable logging for section of LUA script

[ewdpb]

Hi all. I've got a LUA question: Is there a way to force no-logging for part of the script?. Basically, I do not want DTMF entries to be logged or shown to anyone running fs_cli. I tried:

session:execute('log', '0')

but it does not seem to do anything at all.I am writing an application that is supposed to be PCI compliant. Logging caller entries for sensitive information is a no-no

As always, thanks for any help!

 

[Adrian Fretwell]

You can control logging level within a session with the "session_loglevel" application:

<action application="session_loglevel" data="debug"/>

So you could try: session:execute('session_loglevel', 'err') to reduce the logging.

Also, don't get too hung up with the PCI (Payment Card Industry) stuff. You have to apply common sense. Some PCI rules appear to have been written by people who clearly do not understand how computers and networks work. Even if you logged nothing, super users can see what is happening in memory should they wish to do so and a kernel panic / core dump makes a convenient hard copy.

 

[ewdpb]

Hi @Adrian Fretwell , thanks very much for the suggestion. It didn't work though It does not throw an error, it just does not seem to do anything. On the PCI side, you are right, the problem is that even if they do not know, they can block an application from going live, so the less reasons we give them to do so, the better.

 

[Adrian Fretwell]

Do your DTMF entries still get logged if you change the logging level at the fscli?

fsctl loglevel err

I agree with not giving reasons to block an application, but remember, an application by itself cannot claim to be PCI complient. There are so many other factors that contribute to PCI compliance. For example, where is the application run, what data does it process, who has physical access to the system console, who has admin or superuser rights, how were these people vetted, it just goes on and on...

What I'm trying to say is; it doesn't matter if something gets written to a log file as long as there are adequate safeguards in place for securing and processing the log files such that they do not pose a security risk.

 

[ewdpb]

Hi @Adrian Fretwell. Well, if I just run the command on the console it works as intended. However, I do not really see it doing anything when I call it from the app. I just run a quick test calling the github API. What I do is:

console_log('NOTICE', 'Session log changed to ERR (Before)')
session:execute('session_loglevel', 'ERR')
console_log('NOTICE', 'Session log changed to ERR (After)')

--Start Web service test
query_ws()
-- end Web Service test

console_log('NOTICE', 'Session log changed to DEBUG (Before)')
session:execute('session_loglevel', 'DEBUG')
console_log('NOTICE', 'Session log changed to DEBUG (After)')

I would expect that

console_log('NOTICE', 'Session log changed to ERR (After)')

would not actually show up and I would start getting back some DEBUG information after

 session:execute('session_loglevel', 'DEBUG')

In fact what I get is just about everything. Unless I am misunderstanding how the whole thing is supposed to work.



Thanks again and Happy New Year!

 

[Adrian Fretwell]

I may be wrong about this...
I think you can override default logging levels within your dial plan to log more verbosely but you cannot override to log less information. For example:
If, at the console (fs_cli) you execute

 fsctl loglevel err

and in your dial plan you have

<action application="session_loglevel" data="debug"/>

From that point on wards you will see debugging information.
However if you do it the other way around

fsctl loglevel debug

and in the dial plan you have

<action application="session_loglevel" data="err"/>

You will still see ALL the debugging information.

So I think your solution is to make sure your default logging is not DEBUG. (fsctl loglevel err)

 

[ewdpb]

Interesting. I think you are right. I tested it out and it sort of works. I need to play a bit more with it. I think I can make it work. Thanks very much again for your help!