Hello, I was reading up on this error (Could not open dynamic file) which occurred when I tried to use dynamic files, and found the following post:
http://www.mail-archive.com/[email protected]/msg02505.html Now, I run Ubuntu, and the PrivDrop statements are in the rsyslog.conf by default on that distribution. The problem is further described in an Ubuntu bug (although the only Ubuntu-specific problem here is the PrivDrop statements being default on that distribution): https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/484336 The relevant lines in rsyslog.conf are: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup syslog What happens is rsyslog is able to create the dynamic files, but it cannot access them to write to them, as described in the emails earlier on the list. I found that when I created a directory for these files, with 755 permissions owned by syslog and group syslog. The files would get created with 640 permissions owned by syslog:syslog and yet rsyslog would not be able to write to them. Rather than lose the safety provided by PrivDrop I found, based on the bug report above, that all you have to do is change the group to adm and it works: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup adm Then the log files end up being owned by syslog:adm instead of syslog:syslog and rsyslog is able to write to them. I am not sure why this works. What's even more puzzling is that at least on my system (Ubuntu 9.10) syslog is not part of the adm group at all. I'm guessing that when you call the function to drop privileges to a group it doesn't care whether the user you drop to is part of the group you drop to. It is funny though. Anyway I am sending this out in hope that others might benefit from not having to completely dump PrivDrop, and that maybe some light will be shed on why this mechanism is not working properly in this case. It does not make sense that having the right owner still does not result in being able to write to and open files, and that you have to change the group to adm. It seems to me that there is some problem internal to rsyslog that is causing this to happen. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
