Various problems running syslogd with "-u syslog" option
|Canonical Server Team|
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/
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.
> 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:
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/
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).
|Changed in sysklogd:|
|assignee:||nobody → ubuntu-server|
|Mathias Gug (mathiaz) wrote : Re: [Bug 120085] Various problems running syslogd with "-u syslog" option||#7|
|Matt Zimmerman (mdz) wrote : Re: [Bug 120085] Various problems running syslogd with "-u syslog" option||#9|
|Mathias Gug (mathiaz) wrote : Re: [Bug 120085] Re: Various problems running syslogd with "-u syslog" option||#12|
|Matt Zimmerman (mdz) wrote : Re: [Bug 120085] Re: Various problems running syslogd with "-u syslog" option||#16|
|Changed in sysklogd:|
|assignee:||ubuntu-server → canonical-server|