Comment 40 for bug 407862

First - apologies for the vagueness that follows. I'm only an amateur and while I do record configurations I end up with, I don't record much if anything on the way. Second, I got here via installing rsyslog myself on Jaunty and then upgrading to Karmic which may also have confused things. I currently have rsyslog 4.2.0-2ubuntu5.

Anyway, while trying to get to a setup I like, I've been having all sorts of trouble with file/dir permissions. I think I'm ok now and I can get on with the other stuff I want to do but I have a couple of observations/questions which may arise from either the package or my fingers.

When I started looking at rsyslog after the upgrade, I found that rsyslog.conf did not set $DirOwner or $DirGroup at all. Having set those the same as $FileOwner and $FileGroup rsyslog managed to create the directories I want but I still had problems with dynafiles being created and eventually found this bug report.

Following Rainer's link [1] in comment #28 I read in Michael's description that $PrivDropToUser and $PrivDropToGroup should be set the same as $FileOwner and $FileGroup. I had $PrivDropTo as syslog:syslog but $File as syslog:adm. I don't believe I set any of those myself. I've now set all the groups to syslog and things seem to be working now.

This last issue leaves me questions though:
- _must_ $PrivDropTo match $File? I haven't spotted that as a requirement anywhere else or even mentioned in the docs I've read.
- should I have used syslog:syslog or syslog:adm?
- is the intention behind group adm to give read-only access to various admin files for appropriate users?
- if I use syslog:adm, should/must the syslog user be in group adm?