Comment 9 for bug 484336

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.