[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 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [PATCH] multiline syslog patch,
Czichy, Thoralf (Nokia - FI/Espoo) <=