rsyslog.conf file

From bfac3c68f47b8769b0936fb80eeea8880793fd2d Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Fri, 11 Sep 2009 11:23:47 +0200 Subject: added new config directive $omfileForceChown to fix some broken system configs. See ticket for details: http://bugzilla.adiscon.com/show_bug.cgi?id=150 --- doc/rsconf1_omfileforcechown.html | 64 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 doc/rsconf1_omfileforcechown.html (limited to 'doc/rsconf1_omfileforcechown.html') diff --git a/doc/rsconf1_omfileforcechown.html b/doc/rsconf1_omfileforcechown.html new file mode 100644 index 00000000..7415a6f6 --- /dev/null +++ b/doc/rsconf1_omfileforcechown.html @@ -0,0 +1,64 @@ + + +rsyslog.conf file + + +back + +

$omfileForceChown

Type: global configuration directive

Parameter Values: boolean (on/off, yes/no)

Available since: 4.7.0+, 5.3.0+

Default: off

Description:

Forces rsyslogd to change the ownership for output files that already exist. Please note +that this tries to fix a potential problem that exists outside the scope of rsyslog. Actually, +it tries to fix invalid ownership/permission settings set by the original file creator. +

Rsyslog changes the ownership during initial execution with root privileges. When a privelege +drop is configured, privileges are dropped after the file owner ship is changed. Not that this currently +is a limitation in rsyslog's privilege drop code, which is on the TODO list to be removed. See Caveats +section below for the important implications. +

Caveats:

This directive tries to fix a problem that actually is outside the scope of rsyslog. As such, +there are a couple of restrictions and situations in which it will not work. Users are strongly +encouraged to fix their system instead of turning this directive on - it should only be used +as a last resort. +

At least in the following scenario, this directive will fail expectedly: +

It does not address +the situation that someone changes the ownership *after* rsyslogd has started. +Let's, for example, consider a log rotation script. +

rsyslog is started +
ownership is changed +
privileges dropped +
log rotation (lr) script starts +
lr removes files +
lr creates new files with root:adm (or whatever else) +
lr HUPs rsyslogd +
rsyslogd closes files +
rsyslogd tries to open files +
rsyslogd tries to change ownership --> fail as we are non-root now +
file open fails +

+ +Please note that once the privilege drop code is refactored, this directive will +no longer work, because then privileges will be dropped before any action is performed, +and thus we will no longer be able to chown files that do not belong to the +user rsyslogd is configured to run under. + +

So expect the directive to go away. It will not +be removed in version 4, but may disappear at any time for any version greater than 4. + +

Sample:

$FileOwner loguser + $omfileForceChown on

+ +

[rsyslog.conf overview] [manual +index] [rsyslog site]

+ + -- cgit