The clang Pragma()s were not correctly enabled due to the new
gcc version check. Also, gcc 4.2 upwards was not processed
correctly. This broke rsyslog build on the affected platforms.
Note: checking the exact version of clang is more complex than
worth the effort. Even very old versions (down to v 3) support
the macros. So we just check if we compile via clang.
Some old compilers, eg. GCC 4.4.7 on el6 do not support #pragma GCC
diagnostic in functions. Rsyslog has PRAGMA_* macros to handle those
cases, so let's use them.
Even if hostname FQDN is configured, rsyslog internal messages generated
after rsyslog startup and before the first HUP will not necessarily have
FQDN but instead only the shortname of the local host. This commit
fixes the situation.
Special thanks to github user eciii for doing a great bug analysis
and helping us considerably to fix the issue.
closes https://github.com/rsyslog/rsyslog/issues/5218
- Add TLS CRL support tp GnuTLS driver using gnutls_certificate_set_x509_crl_file.
- Add code in OpenSSL driver that works with OpenSSL 1.0.2 and higher.
Disable feature on older features with error message.
- Some cosmetic changes
- testbench: Add revoked certificate for testing (Including CRL PEM and other files)
- testbench: Add testcase for gtls and ossl testing revoked certificates
The option allows to drop the capabilities to only
the necessary set, to minimize security exposure in
case there was ever a mistake in a networking
plugin or some other input resource. Moreover, it adds
ability to change uid and gid while retaining the
previously specified capabilities. Resolves#4986
Add ability to change uid and gid while retaining the capabilities previously specified
rsyslog.conf may affect the host's local name. These changes were
so far only activated after the first HUP. This patch now ensures
that the configured local host name is applied correctly throughout
all processing, including early startup.
This patch causes a slight change of behaviour. However, the behaviour
was inconsitent before. Now it is consistent and according to the config.
Please note: this patch also exposes a global entry point via "regular"
dynamic loading as this makes things much easier to do. This is in-line
with ongoing simplification effort.
Finally, we also remove a CI test that we do no longer need because
the problem covered is now addressed differently and the original issue
can no longer occur.
closes https://github.com/rsyslog/rsyslog/issues/4975
Commit 829a6f6 "CI: improve use of github action matrix feature;
optimization" has introduced use of #pragma GCC diagnostic in function
doNameLine() of runtime/conf.c. This is not supported by old compilers
like GCC 4.4.7 on el6.
Matrix feature was initially barely usable because github did not permit
to restart just failed jobs. This has changed. So we now migrate back to
the use of matrix feature where it is useful.
We also reduce the number of plain compile tests to newest and oldest
compiler version only. This saves CI ressources. The important other
ones (distro default!) are used during other CI tests anyways.
We also fix some minor coding errors detected by new compiler builds.
None of them seems to be related to any real issues.
This is a fine-tuning option which permits to control whether or not
rsyslog shall alays take the flow control setting from the message. If
so, non-primary queues may also block when reaching high water mark.
This permits to add some synchronous processing to rsyslog core engine.
However, it is dangerous, as improper use may make the core engine
stall. As such, enabling this option requires very careful planning
of the rsyslog configuration and deep understanding of the consequences.
Note that the option is applied to individual queues, so a configuration
with a large number of queues can (and must if use) be fine-tuned to
the exact use case.
The rsyslog team strongly recommends to let the option turned off,
which is the default setting.
see also https://github.com/rsyslog/rsyslog/issues/3941
If the same name is specified for multiple queues, the queue files
will become corrupted. This commit adds a check during config parsing.
If duplicate names are detected the config parser errors out and the
related object is not created.
Note: this may look to a change-of-behaviour to some users. However,
this never worked and it was pure luck that these users did not run
into big problems (e.g. DA queues were never going to disk at the
same time). So it is acceptable to error out in this hard error case.
closes https://github.com/rsyslog/rsyslog/issues/1385
When the work directory has not been set or is invalid, state files
are created in the root of the file system. This is neither expected
nor desirable. We now complain loudly about this fact. For backwards
compatibility reasons, we still need to support running imfile in
this case.
closes https://github.com/rsyslog/rsyslog/issues/1296
When loading CA, Cert or Keyfile, the OpenSSL error stack will be output into LogError.
Also added 3 tests with invalid certificates/keyfiles for testbench.
previously, truncation was only detected at end of file. Especially with
busy files that could cause loss of data and possibly also stall imfile
reading. The new code now also checks during each read. Obviously, there
is some additional overhead associated with that, but this is unavoidable.
It still is highly recommended NOT to turn on "reopenOnTruncate" in imfile.
Note that there are also inherant reliability issues. There is no way to
"fix" these, as they are caused by races between the process(es) who truncate
and rsyslog reading the file. But with the new code, the "problem window"
should be much smaller and, more importantly, imfile should not stall.
see also https://github.com/rsyslog/rsyslog/issues/2659
see also https://github.com/rsyslog/rsyslog/issues/1605
GCC, starting at least with version 8, is now really overdoing with it's
warning messages. We turn those off that either cause an enormous amount
of false positives or flag perfectly legal code as problematic.
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.
In theory, TZ should be set by the OS. Unfortuantely, this seems
to be not the case any longer on many Linux distros. We now check
it and set it appropriate if not already given.
closes https://github.com/rsyslog/rsyslog/issues/2054
imfile: Initial implementation of solaris FEN API (without wildcards)
FEN API is used to implement simular event based file
monitoring like with inotify.
This commit provides partial functionality. It supports event-driven
processing of files but does not yet provide wildcard functionality.
Wildscards will be provided by a later commit.
This can be committed as-is because the previous code did also
not provide wildcard support, so this is an improvement for
Solaris in any case.
see also https://github.com/rsyslog/rsyslog/issues/1954
the finalize_it: label is required, but not always used, which each
time results in a compiler warning that needs to be worked around.
Now this is fixed once and for all for gcc and clang - the others
will probably not complain in any case. Great solution until something
comes up that makes us need a revision.
refactored the method so that it consistent in all functions and easier
to follow. Most importantly, now an as simple as possible locking paradigm
of lock ... unlock within the function. Hopefully easier to understand
both for humans and static code analyzers.
this in almost all cases indicates a real problem that the user
should be made aware of
For a case where the missing error message caused confusion
see also https://github.com/rsyslog/rsyslog/issues/1867
When a message larger than supported by the UDP stack is to be sent,
EMSGSIZE is returned, but not specifically handled. That in turn
will lead to action suspension. However, this does not make sense
because messages over the UDP max message size simply cannot be sent.
This patch truncates the message in question and reports an error
message with the condition.
closes https://github.com/rsyslog/rsyslog/issues/1654
