/etc/rsyslog.conf permissions incorrect/missing for creation of dynamic files

Just found this and it's covering similar ground to bug #407862. From my experience in that bug:

I agree that $DirOwner and $DirGroup should be configured.
I agree that $DirGroup, $FileGroup and $PrivDropToGroup have to be the same for rsyslog to create dynamic files properly.

However I don't believe $PrivDropToGroup _should_ have to be the same as the others.

I'm also uncomfortable running rsyslog as adm as this gives access to facilities which are irrelevant and, conversely, I don't like the idea of putting a user in group adm (so they can see logs amongst other things) into group syslog although that's waht I am doing at the moment.

Same problem for me.
Changing "$PrivDropToGroup syslog" to "$PrivDropToGroup adm" fixes this.
Am using Ubuntu 10.04 LTS Server

Using 10.04 LTS. After fixing privileges it works with dynamic files - but only under very little load. When I pointed three ASA firewalls (tens of messages per second each) to my server, rsyslog lost ability to write files again. Aftre service restart it works for several seconds and dies. RIP.

Switched back to old trusty syslog-ng which gives me no problems even with much higher load.

I agree with the security concerns brought up by @George Klein .

For some informative discussion on this problem, see the following message thread:

http://kb.monitorware.com/trouble-getting-dynamic-files-work-t10054.html

Very strange. I had to uncomment these two lines for it to work

$PrivDropToUser syslog
$PrivDropToGroup syslog

Seems like the complete opposite of what everyone else here is saying.

Ubuntu 10.04.3 LTS x86

Edit: I ment to say I had to comment out... NOT uncomment

doing this

#$PrivDropToUser syslog
#$PrivDropToGroup syslog

---
Very strange. I had to uncomment these two lines for it to work

$PrivDropToUser syslog
$PrivDropToGroup syslog

Seems like the complete opposite of what everyone else here is saying.

Ubuntu 10.04.3 LTS x86

No, that's the same.

Commenting out those lines makes rsyslogd run as root (which is very dangerous)

Setting $PrivDropToGroup adm (to match $FileGroup adm) is a less dangerous solution to the problem, although still not ideal from a security point of view.

Now, rsyslogd has sufficient rights to create the directory and even to create the file with 0 byte size - but decines to append to it. strace -f -p <pid> shows:

...
[pid 29688] access("/var/log/network/2011/11/17/rtr1-13.log", F_OK) = 0
[pid 29688] open("/var/log/network/2011/11/17/rtr1-13.log", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_LARGEFILE|O_CLOEXEC, 0640) = 1
[pid 29688] fchown32(1, 101, 4) = -1 EPERM (Operation not permitted)
...

Aha: so rsyslogd is trying to chown to syslog:adm, but it cannot because it is running as syslog:syslog!

IMO this should be treated as a non-fatal error, as creating files owned by syslog:syslog when running as syslog:syslog is a reasonable thing to do.

I ran into this today. If I understand correctly the privilege drop happens before the chown though it should be the other way around, the chown should happen while root and then privileges should be dropped. And in any case the failure of chown should not prevent the logs from writing. The solution seems to be that $FileGroup and $PrivDropToGroup should match. From a security perspective setting $FileGroup to to syslog is the safest course of action.

I ran into this problem today, too.
I do not fully understand about it yet, but changing "$PrivDropToUser syslog" to "$PrivDropToGroup adm" looks like working for me.

Encountered on Ubuntu 11.04, changing $PrivDropToGroup adm does not allow dynamic files to be created.

I'm just discovering this same issue, and agree that "$PrivDropToGroup adm" does not work.

I confirm that the patch in comment #1 works on Lucid. Setting the $DirOwner and $DirGroup was essential to have rsyslog to creating new directories that are part of the path to the dynamic files ("/var/log/central/%$YEAR%/%$MONTH%/%$DAY%/%HOSTNAME%.log").

I agree that using "$PrivDropToGroup adm" comes with a bigger risk than using "$PrivDropToGroup syslog" but the former provides out of the box compatibility with other tools like logcheck.

So what happens?
Will it ever be fixed in Ubuntu repos or I need to create a deb package for rsyslog myself and distribute it with my software?

I'm using Ubuntu 12.04 and the bug is still there.

Im another user who has experienced this bug in 12.04.
The drop privileges workaround supplied above does not fix the problem for me.

We changed to this and chowned some dirs which needed but rarely needed.

$PrivDropToUser syslog
$PrivDropToGroup adm

On 22 February 2013 14:40, Vincens Mink <email address hidden> wrote:

> 12.04.1 LTS
> Workaround does not work.
> But if you drop both Group and Owner to adm dynamic files can be created,
> have not tried with directories.
>
> $PrivDropToUser adm
> $PrivDropToGroup adm
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (878857).
> https://bugs.launchpad.net/bugs/484336
>
> Title:
> /etc/rsyslog.conf permissions incorrect/missing for creation of
> dynamic files
>
> Status in “rsyslog” package in Ubuntu:
> Confirmed
>
> Bug description:
> Binary package hint: rsyslog
>
> When using templates to create dynamic directories and files with
> rsyslog, rsyslog can create the directories, but does not have the
> appropriate permissions to create files within them.
>
> By default, directories created by rsyslog are owned root:root and
> generates an error in /var/log/syslog as follows:
>
> rsyslogd: Cout not open dynamic file '...' -
> discarding message
>
> Furthermore, adding $DirOwner and $DirGroup to match those of
> $FileOwner and $FileGroup, the setting '$PrivDropToGroup syslog'
> further prevents rsyslog from creating dynamic files. Setting
> '$PrivDropToGroup adm' resolves this issue.
>
> Attached is a patch that corrects these issues.
>
> Rich
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/484336/+subscriptions
>

This bug was fixed in the package rsyslog - 7.4.4-1ubuntu2

---------------
rsyslog (7.4.4-1ubuntu2) trusty; urgency=low

  * debian/rsyslog.postinst: Make sure /var/log is owned by group syslog and
    is group-writeable (LP: #1256695).
  * Ensure that rsyslogd can create files in group adm, even when dropping
    group privileges to syslog (LP: #484336):
    - debian/patches/10-initgroups.patch: Try to set appropriate
      supplementary groups before dropping UID.
    - debian/rsyslog.postinst: Add syslog user to group adm.
 -- Colin Watson <email address hidden> Wed, 04 Dec 2013 13:12:07 +0000