hi, 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 approach. 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? Cheers, Thoralf
syslog_multiline_4_4.patch
Description: syslog_multiline_4_4.patch