Comment 37 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.

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?

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.

Thanks very much for your Ubuntu concern. I appreciate it!