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
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
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
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.
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 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!
As it seems, different C compilers have different rules/interpretations
on inline functions. The current code base did not properly obey all C99
rules. We fix this by converting some functions to macros and others to
include the necessary C99 plumbing. We also remove some inline attributes
for functions where this seems to be to agressive (aka "function to big").
This fixes build problems in some environments and is a general code
cleanup measure.
closely related, thus done in a single commit:
- bugfix: invalid data size for iMaxLine global property
It was defined as int, but inside the config system it was declared as
size type, which uses int64_t. With legacy config statements, this could
lead to misadressing, which usually meant the another config variable was
overwritten (depending on memory layout).
closes https://github.com/rsyslog/rsyslog/issues/205
- bugfix: negative values for maxMessageSize global parameter were permitted
