Comment 38 for bug 407862

> I agree it's probably (b), with the addendum that certainly part of the
> problem was previous rsyslog versions, which created the files as root.
> If that were the only problem, I suppose the packaging scripts could
> change permissions at install time, but that would require special
> logic
> to handle the case where the user set their own user/group.
>
> I don't have any evidence yet that another program is creating/changing
> permissions on those files (all the current reports are explainable by
> rsyslog creating them as root before the user/group config change --
> there was a period of time where rsyslog was running unprivileged, but
> the config told it to create files as root, my bad), but I haven't done
> an audit to make sure it's the case. I agree that such a review would
> be helpful.

OK, if it is only this transient problem, I think the current fix is a good
one to solve the situation. Nevertheless, you correctly point out that some
issue may occur if the user changes the file owner. Of course, one can argue
that then this is a user error, but I agree it would be useful to have some
utility to aid the user in that process. At least some doc should explain the
situation and what to watch for.

> So on the theory that the only real issue is previous rsyslog versions
> (until such an above review finds anything), the current 'force owner
> on
> open' behavior could conceivably be replaced by some install-time
> chowning, but to do that right (respect any user modification of either
> user/group or output files), it would involve parsing rsyslog.conf &
> rsyslog.conf.d/*.
>
> Maybe for this usecase (distro changing default user/group), when
> rsyslog becomes fully-unprivileged, it could include a utility program
> called, say, rsyslog-fix-permissions that would run as root and chown
> all its output files?

This sounds very reasonable. I will keep this on my mind when working on the
new privilege drop code (whenever this may be). I tend to think that this
must be done by an interactive instance of rsyslogd, because only it has the
full knowledge of the configuration. But it may be really tricky for
dynafiles, where rsyslogd only knows at runtime, "as it happens" which files
need to be opened. Anyway, I think we can postpone that discussion until I
finally begin to implement that functionality.

> I suppose a second alternative is to force a logrotate that doesn't
> create the files and let rsyslog recreate its files. But that relies
> on
> the logrotate config and seems a little forceful. I don't think it
> would be wise to logrotate when an administrator isn't expecting it.

full ack

I still have one concern, and that is probably easy to verify: what happens
if logrotate runs? Does it create the files with the proper owner and
permissions? And if so, how does it know?

I understand that in Ubuntu terms, the "rsyslog logrotate script" is
considered part of the rsyslog package, but from the rsyslog project's POV
(mine ;)), this is something totally external, so I neither know exactly what
happens nor do I have any control over it. Actually, logrotate is my primary
concern in regard to overall system stability.

Rainer