Don't run as root

Here's an initial debdiff that does this as well as cleanly upgrades from sysklogd to rsyslog. There's still an issue with kern.log that I'm looking into. This is not done yet, this is just an alpha preview. :)

OK, better version that switches to syslog user earlier to avoid issue with the kmsg pipe not giving us any data if we read from it before switching uid/gid.

So things this patch does:
1) Backports the 'DropPriv' config values from upstream
2) Copies the dd-shovels-proc-kmsg-to-readable-location logic from sysklogd and adds a config value to change klog location
3) Handles upgrade from sysklogd by doing the following:
   A) Splits rsyslog.conf into two parts: config stuff and rules
   B) If we're upgrading to this version or later and /etc/syslog.conf exists *and* is modified by user, then copy it to /etc/rsyslog.d/default.conf
   C) Merge our default rules into /etc/rsyslog.d/default.conf using ucf

Third time's the charm. After talking with upstream, I realized we need to initialize modules while still root (so that they can grab privileged port or whatnot). So here I split out the initialization and the running of modules, so that now they are only run after privileges are dropped, but initialized beforehand.

Here are a couple more improvements, from suggestions by the Debian maintainer:
1) Add comment in rsyslog.conf noting that the rules are in /etc/rsyslog.d
2) Don't parse /var/lib/dpkg/status directly, use dpkg-query
3) Rename default.conf to 50-default.conf

It looks like Karmic just got rsyslog 4.2.0 in a case of spectacular timing. Would you mind reviewing & updating your changes with respect to this new version, and then resubscribing ubuntu-universe-sponsors?

Ah, well. Here's the 4.2.0 debdiff. Basing off 4.2.0 meant I could drop the 'backport of DropUserPriv' bit of the patch, which is nice.

This bug was fixed in the package rsyslog - 4.2.0-1ubuntu1

---------------
rsyslog (4.2.0-1ubuntu1) karmic; urgency=low

  * Run as rsyslog:rsyslog (LP: #250827, LP: #388608)
    - debian/control: Depend on adduser
    - debian/rsyslog.postinst: Create syslog user
    - debian/rsyslog.postrm: Delete syslog user on purge
    - debian/rsyslog.conf: Use DropPriv config fields
  * Allow reading /proc/kmsg when non-root
    - debian/rsyslog.init: Spawn a dd instance that shovels the /proc/kmsg
      data to a pipe that rsyslog can read (based on Martin Pitt's similar
      change to sysklogd).
    - debian/patches/deroot.patch: Support a KLogPath config field
      to change where the klog plugin looks and only start input modules
      after we drop privileges, as reading when root interferes with
      future reads as syslog.
    - debian/rsyslog.conf: Use KLogPath field to point to dd pipe
  * Cleanly upgrade from sysklogd
    - debian/default.conf, debian/rsyslog.conf:
      Break out the default rules into their own config file
    - debian/rsyslog.install: Install it in /usr/share/rsyslog
    - debian/rsyslog.postinst: If present, copy /etc/syslog.conf into
      /etc/rsyslog.d/default.conf. Then merge our own default.conf

 -- Michael Terry <email address hidden> Mon, 29 Jun 2009 08:37:43 -0400

> 2) Copies the dd-shovels-proc-kmsg-to-readable-location logic from sysklogd and adds a config value to change klog location

> * Allow reading /proc/kmsg when non-root
> - debian/rsyslog.init: Spawn a dd instance that shovels the /proc/kmsg
> data to a pipe that rsyslog can read (based on Martin Pitt's similar
> change to sysklogd).

Please, could this be reverted? This was an ugly hack that was used by sysklogd. It keeps another process running (dd) just copying data from one descriptor to another.

Rsyslog allows it to be run as root, set itself up, and then drop its privileges to another user. This is the same method that is used for at least three decades when processes should run as non-privileged users but still need to open some privileged files/ports (only at startup). Using dd to copy data from one pipe to another not only is unnecessary, it also adds another single point of failure.

http://wiki.rsyslog.com/index.php/Security#Dropping_Privileges

In short, set $PrivDropToUser and $PrivDropToGroup to the syslog user, and just run rsyslog as root.

I just found that the reason for dd is that Linux doesn't allow reading from the /proc/kmsg open descriptor without root privileges (as opposed to restricting just the open() call). The syslog-ng that I was using until now used the CAP_SYS_ADMIN capability to keep access to /proc/kmsg after dropping root privileges. It seems that rsyslog isn't currently programmed to use this capability, so my previous suggestion wouldn't work.

For now I switched back to syslog-ng, so that I don't need the extra 'dd' process running and still run the syslog daemon as an unprivileged user.

Sorry for the noise.