Drop the dd process

Bug #517773 reported by Martin Pitt on 2010-02-05
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)
Medium
Canonical Foundations Team
Lucid
Medium
Canonical Foundations Team

Bug Description

Binary package hint: rsyslog

Until recently, the kernel required root privileges to open /proc/kmsg _and_ for reading from it. This was now fixed (see bug 515623).

To work around this, rsyslog currently installs an upstart job (/etc/init/rsyslog-kmsg.conf) which runs a dd instance which shovels /proc/kmsg to a FIFO in /var/run, so that rsyslog can start and run as system user "syslog".

The dd process requires a ridiculous amount of CPU during startup, though, since it is running with bs=1 to not miss stuff:
http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100205-1.png

So with the fixed kernel, rsyslog can now start up as root, open /proc/kmsg, and drop the effective user to "syslog".

Some things to watch out for:

 * We should keep the /etc/init/rsyslog-kmsg.conf job and start dd if we are running on a < 2.6.32 kernel, so that we do not break kernel logging when upgrading a previous Ubuntu release to lucid, or a lucid user is running a previous kernel.

 * rsyslog should use the FIFO if it exists, and fall back to /proc/kmsg.

 * rsyslog must not close/reopen the fd to /proc/kmsg if it gets a SIGHUP, since it already dropped privileges.

Related branches

Martin Pitt (pitti) on 2010-02-05
Changed in rsyslog (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Martin Pitt (pitti) wrote :

The other implementation option would be to drop the dd upstart job for good, and just let rsyslogd run as root if it detects that reading from /proc/kmsg requires root.

Test case schema:

$ sudo python
[sudo] password for martin:
>>> import os
>>> f=open('/proc/kmsg')
>>> os.seteuid(1000)
>>> f.read(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 1] Operation not permitted

Changed in rsyslog (Ubuntu Lucid):
importance: Undecided → Medium
tags: added: ubuntu-boot
Colin Watson (cjwatson) on 2010-02-05
Changed in rsyslog (Ubuntu Lucid):
status: New → Triaged
milestone: none → ubuntu-10.04-beta-1
Martin Pitt (pitti) wrote :

For the record: With the current kernel it is sufficient to change $KLogPath to /proc/kmsg (in /etc/rsyslog.conf); it already does the right thing of starting as root, opening the fds, and dropping privs only afterwards (I get a fully working kern.log).

So the only thing we need to add there is the check if reading as user is allowed, and if it's not, to not drop privileges.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rsyslog - 4.2.0-2ubuntu6

---------------
rsyslog (4.2.0-2ubuntu6) lucid; urgency=low

  * debian/rsyslog.rsyslog-kmsg.upstart:
    - Drop this additional job; kernel changes have meant that rsyslog
      may read from /proc/kmsg directly after dropping privileges.
      LP: #517773
  * debian/rsyslog.preinst:
    - Remove on upgrade
  * debian/rsyslog.conf:
    - Restore to reading from /proc/kmsg
 -- Scott James Remnant <email address hidden> Wed, 17 Feb 2010 12:23:01 +0000

Changed in rsyslog (Ubuntu Lucid):
status: Triaged → Fix Released
Pavel Rojtberg (rojtberg) wrote :

after this change rsyslog started eating 100% CPU as /proc/kmsg is not user-readable here. Maybe that is because I am using the 2.6.33 kernel from the mainline-ppa, but according to this bug it should work nevertheless, right?

Martin Pitt (pitti) wrote :

Right, that's the problem that was mentioned before: rsyslog needs to check if it can read from /proc/kmsg as non-root, and not drop privileges if not. In other works, seteuid(), read() -> on fail, seteuid(0) and keep it that way, on success -> setuid() -> permanently drop privs.

Pavel Rojtberg (rojtberg) wrote :

I think this is not really a duplicate, but everybody with a different kernel is having fun because of this change: https://bugs.edge.launchpad.net/ubuntu/+source/rsyslog/+bug/523468

or gerson (orgerson-devel) wrote :

should i try to install the rsyslog (4.2.0-2ubuntu6) package on karmic (it affects karmic too)?
if its possible...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers