Comment 67 for bug 407862

I think there are also some subtle issues with the patch. 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

So while this fix is definitely useful, it does not - and conceptually can not - address these issues. Actually, I consider the those parts of the system that create the wrong ownership to be broken. So what the patch actually tries to fix something outside of the scope of rsyslog.

Again, I think it is useful, but not as a real cure but only as an aid to reduce the effects of some other, wrong actions. I assume that it will work most of the time.

However, once the $PrivDrop... code is refactored, this patch 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 it probably is a good idea to look at the rest of the system.