Binary package hint: sysklogd
Ubuntu tries to run syslogd with uid syslog rather than root, for improved security. As found in bug #103232, in fact it still runs as root by default because /etc/default/syslogd, sourced from /etc/init.d/sysklogd, doesn't set $SYSLOGD to the correct value.
After correcting this problem and running syslogd with "-u syslog", I have found various other problems. The primary problem is that after the log files are rotated (by /etc/cron.[daily|weekly]/sysklogd), nothing is recorded: this is due to a permissions issue. Here's the description of the -u option in syslogd(8):
> The syslogd daemon runs with full root privileges by default. If
> you specify this option, the daemon will drop its privileges to
> the given user (and the primary group of this user) before
> starting up logging. This greatly reduces the potential impact
> of exploitable security holes in syslogd.
> syslogd will still open all log files as root at startup. How‐
> ever, after receiving a SIGHUP signal (which causes the daemon
> to restart) the log files will be reopened as the non-privileged
> user which fails if the log files are only writeable by root. If
> you need to restart the daemon using the signal, then you have
> to adapt the permissions of your log files to be writeable by
> the specified user (or its primary group).
The daily/weekly (ana)cronjobs issue:
/etc/init.d/sysklogd reload-or-restart
which in Feisty issues a SIGHUP signal (in earlier Ubuntu releases, the sysklogd script stops and restarts syslogd). This means, according to the second paragraph of the above description, that the log files aren't writable since they're owned by root, so nothing further gets recorded by syslogd.
The simplest fix for most current users, I would think, is always to run sydlogd as root. Let's persist, though.
The man page suggests "adapting" the permissions. The (ana)cronjobs issue:
savelog -g adm -m 640 -u root ...
These options are wrong because they don't match the -u set in the now corrected /etc/default/syslogd (and the implicit -g). If we correct these options, syslogd should work correctly after a SIGHUP. However, it doesn't make a lot of sense to have the first set of files created after boot be owned by root, but later files be owned by syslog. It would make more sense to modify syslogd to create the first set of files as syslog too. I've looked at the source, and it seems like a simple change near the first call to init().
There's still a further problem, a security issue, not related to running with uid syslog. syslogd(8), under BUGS, says:
> Syslogd doesn’t change the filemode of opened logfiles at any stage of
> process. If a file is created it is world readable. If you want to
> avoid this, you have to create it and change permissions on your own.
> This could be done in combination with rotating logfiles using the
> savelog(8) program that is shipped in the smail 3.x distribution.
> Remember that it might be a security hole if everybody is able to read
> auth.* messages as these might contain passwords.
And yes, when syslogd starts after boot, auth.log doesn't exist, and syslogd creates it world readable. After that, savelog touches new files with mode 640 and chmods existing files to mode 640, but for the first week after boot, auth.log is world-readable, I believe.
Perhaps syslogd should not create world-readable files by default, or should have a -m option to set the mode. Perhaps too /var/log/ shouldn't be world-readable (it isn't in Red Hat).
Sorry, the penultimate paragraph above is probably wrong, since auth.log would normally exist at boot time, with mode 640.