This parameter controls whether or not rsyslog aborts when a name ID
lookup fails (for user and group names). This is necessary as a security
measure, as otherwise the wrong permissions can be assigned or privileges
are not dropped.
CHANGE OF BEHAVIOR
The default for this parameter is "on". In previous versions, the default
was "off" (by virtue) of this parameter not existing. As such, existing
configurations may now error out.
We have decided to accept this change of behavior because of the potential
security implications.
closes https://github.com/rsyslog/rsyslog/issues/4164
termination condition was not properly checked; this lead to
premature termination after patch 1c8712415b9 was applied.
It is open to debate if patch 1c8712415b9 changed the module
interface. Actually it looks like this was previously not
well thought out.
closes https://github.com/rsyslog/rsyslog/issues/3760
also fix a problem in handling this parameter when rsyslog processed
internal messages itself (it did not work). As the parameter was
introduced today, we do not flag this follow-up commit as "bugfix".
The issue was noticed when we added the additional tests.
see also https://github.com/rsyslog/rsyslog/issues/3650
see also https://github.com/rsyslog/rsyslog/issues/3639
permits to specify a severity filter for internal message. Only
messages with this severity level or more severe are logged.
Orignally this was done in rsyslog.conf as usual: you can filter
rsyslog messages on severity, just like any other. But with systemd,
we now emit primarily to the journal, and this is outside of rsyslog's
rule engine and so regular filters do not apply (at least in regard
to the journal). Logging to journal is good, because finally
folks begin to see the messages (traditional distro configs discard
them, for whatever is the reason).
This commit implements a global setting for a severity-based filter
for internal messages, before submitted to journal. So it's not 100%
of what rsyslog can do, but at least some way to customize.
see also https://github.com/rsyslog/rsyslog/issues/3639
This leads to a refactoring of the looking code; issue was caused
by new TTL cache expiration code which placed not semantics on the
cache. These were not properly handled under all circumstances.
- Corrected ANON Cipher handling in ossl / gtls driver.
- removed error when no CA is configured for ANON Mode in gtls dirver.
- Set GNUTLS Debug level to 2, so we see more informations about gnutls errors
in rsyslog debug mode.
- fixed tcpdump parameters not using TLS in manytcp-too-few-tls-vg.sh
- fixed minor memory leak in shutdown destructor of ossl tls driver.
Add new global setting 'reportChildProcessExits' with possible values
'none|errors|all' (default 'errors'), and new global function
'glblReportChildProcessExit' to report the exit status of a child
process according to the setting.
Invoke the report function whenever rsyslog reaps a child, namely in:
- rsyslogd.c (SIGCHLD signal handler)
- omprog
- mmexternal
- srutils.c (execProg function, invoked from stream.c and omshell)
Remove redundant "reaped by main loop" info log in omprog.
Promote debug message in mmexternal indicating that the child has
terminated prematurely to a warning log, like in omprog.
Closes#3281
while this is useful for users as well, we have done it so
that we can handle slow CI systems during CI runs. It is also
required for massively parallel testing, which makes each
individual test rather slow.
With the new settings, the testbench framework can now set
longer timeouts by defaults. Also updated framework accordingly.
This provides a new-style alternative to $AbortOnUncleanConfig.
Note that a testbench test was changed to the new syntax. Adding
an additional test did not look useful, as the testbench still
sufficiently tests old and new method.
closes https://github.com/rsyslog/rsyslog/issues/2744
In the community we frequently discuss handling of oversize messages.
David Lang rightfully suggested to create a central capability inside
rsyslog core to handle them.
We need to make a distinction between input and output messages. Also,
input messages frequently need to have some size restrictions done at
a lower layer (e.g. protocol layer) for security reasons. Nevertheless,
we should have a central capability
* for cases where it need not be handled at a lower level
* as a safeguard when a module invalidly emits it (imfile is an example,
see https://github.com/rsyslog/rsyslog/pull/2632 for a try to fix it
on the module level - we will replace that with the new capability
described here).
The central capability works on message submission, and so cannot be
circumvented. It has these capabilities:
* overisze message handling modes:
- truncate message
- split message
this is of questionable use, but also often requested. In that mode,
the oversize message content is split into multiple messages. Usually,
this ends up with message segments where all but the first is lost
anyhow as the regular filter rules do not match the other fragments.
As it is requested, we still implemented it.
- accept message as is, even if oversize
This may be required for some cases. Most importantly, it makes
quite some sense when writing messages to file, where oversize
does not matter (accept from a DoS PoV).
* report message to a special "oversize message log file" (not via the
regular engine, as that would obviously cause another oversize message)
This commit, as the title says, handles oversize INPUT messages.
see also https://github.com/rsyslog/rsyslog/issues/2190
closes https://github.com/rsyslog/rsyslog/issues/2681
closes https://github.com/rsyslog/rsyslog/issues/498
Note: this commit adds global parameters:
* "oversizemsg.errorfile",
is used to specify the location of the oversize message log file.
* "oversizemsg.report",
is used to control if an error shall be reported when an oversize
message is seen. The default it "on".
* add global parameter "oversizemsg.input.mode"
is used to specify the mode with which oversized messages will
be handled.
the config system actually does not permit "-" inside parameter
names. This has now been changed to "shutdown.enable.ctlc".
Note: this was never released and only present in 8.33 pre-release
versions.
closes https://github.com/rsyslog/rsyslog/issues/2482
It can be useful to ctl-c out of rsyslog, even if it is started via
-n, especially inside containers. The new config setting permits
to enable this capability.
closes https://github.com/rsyslog/rsyslog/issues/533
This was still available, but had no effect (for ~10 years or so). The
plumbing is now removed. If someone tries to use the option, an
error message is generated.
closes https://github.com/rsyslog/rsyslog/issues/2280
The way the default was set could lead to a race if e.g. two internal
messages were emitted at startup when the property was not yet set. This
has been seen to happen in practice. It had no bad effect except a very
small stationary memory leak, but made using thread analyzers unreliable
(as it was rightfully detected as a problem).
closes https://github.com/rsyslog/rsyslog/issues/2012
This happens if there is a problem with the timezone parameters.
Affects only startup, once started, no problem exists.
Detected by Coverty scan; CID 185414
The variable system inside rsyslog is JSON based (for easy consumption
of JSON input, the prime source of structured data). In JSON, keys
("variable names") are case-sensitive. This causes constant problems
inside rsyslog configurations. A major nit is that case-insensitivity
option inside templates (even if turned on) does not work with JSON
keys because they of inner workings*1.
It is much more natural to treat keys in a case-INsensitive way (e.g.
"$!Key" and "$!key" are the same). We do not expect any real problems
out of this, as key names only differing in case is highly unlikely.
However, as it is possible we provide a way to enable case-sensitivity
via the global(variables.casesensitve="on") global config object.
Note that the default is to do case-insensitive matches. The reason
is that this is the right thing to do in almost all cases, and we do
not envision any problems at all in existing deployments.
*1 Note: case-insensitivity in rsyslog is achieved by converting all
names to lower case. So that the higher speed of strcmp() can be used.
The template option does actually that, convert the template keys to
lower case. Unfortunately, this does not work with JSON, as JSON keys
are NOT converted to lower case.
closes https://github.com/rsyslog/rsyslog/issues/1805
This permits to put a hard limit on the number of messages that can
go to stderr. If for nothing else, this capability is helpful for the
testbench. It permits to reduce spamming the test log while still
providing the ability to see initial error messages. Might also be
useful for some practical deployments.
closes https://github.com/rsyslog/rsyslog/issues/1841
When the global defaults for certificates are set and the certificate
files cannot be accessed, rsyslog aborts. This is caused by a failure
in certificate-file-validity check code. It can only happen right at startup.
Also, the invalid certificate file is still set, causing follow-on problems.
closes https://github.com/rsyslog/rsyslog/issues/1786
This occured when liblogging-stdlog was used, and was used by default (without
explicit configuration). This is a regression of the new default, which does
not correctly call stdlog_open() in the default case.
closes https://github.com/rsyslog/rsyslog/issues/1442
This is caused by uninitialized net static structure in glbl objUse(net)
is not called after start of glbl module.
It looks like it is not possible to use objUse(net) when glbl module
starts. So we call it inside of glblDoneLoadCnf().
MsgSetRawMsg() did not check max message size. So if an input module
submitted a too-long message, it was silently accepted. This now adds
a check and truncates the message if too long. If not turned off, this
will also be logged as a rsyslog error message.
TODO: currently only partly implemented!
