[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] multiline syslog patch

From: Czichy, Thoralf (Nokia - FI/Espoo)
Subject: [PATCH] multiline syslog patch
Date: Mon, 24 Oct 2016 13:49:49 +0000


attached a patch that builds on the existing "log interactive commands to 
syslog" bash feature (SYSLOG_HISTORY). This capability 
is used in some of our devices to be able to track which management operations 
were executed on them using bash (with 
appropriate legal information at login). This helps in troubleshooting. Due to 
privacy and security issues, as a general-purpose
functionality on a generic multi-user system this is probably not something 
administrators want to enable. That's probably also
the reason why in many Linux distros the capability is compiled out.

Quickly googling the issues suggests an alternative solution defining an 
explicit bash DEBUG trap function that uses the "fc"
command to query the last command and then log that. This is certainly one 
solution, but it seemed overly complex to invoke fc
and a subsequent logging command to achieve this. Also traps can be easily 
overwritten by operators. Also there seem to be
issues with the fc-in-DEBUG-trap approach creating repeating log entries if 
users press CTRL-C in the middle of entering a
command. So building on the existing SYSLOG_HISTORY seemed a more reasonable 

Anyway the attached patch builds on the existing logging-to-syslog capability 
(re-using the existing SYSLOG_HISTORY define)
and is only compiled if this define is explicitly given, e.g., via "make 
CPPFLAGS=-DSYSLOG_HISTORY". It hooks into the 
DEBUG trap and only logs the complete command if the DEBUG trap code in bash is 
hit. This also means that multi-line
commands are only logged in full when they are actually executed and not 
one-by-one for each line. The line-by-line logging
had the issue that logs were generated even if the user did not finish the 
multi-line command and pressed CTRL-C, for example. 
Also the behavior is now to log the command again if the same command is 
executed again. Previously invoking the same command 
again was not logged. Also note that users can disable the logging, for 
example, by disabling history logging via "set +o history".
So additional work is needed if someone would want to evolve this into 
fully-forced syslog logging.

What do you think? 


Attachment: syslog_multiline_4_4.patch
Description: syslog_multiline_4_4.patch

reply via email to

[Prev in Thread] Current Thread [Next in Thread]