On Mon, 2008-11-17 at 19:40 -0200, Florian Grandel wrote:

I Matt and Bazsi,

as Bazsi said, the problem is less one of syslog-ng but one of permissions in the kernel. Access to /proc/kmsg is not only governed by file permissions but also by process capabilities. In this case reading from /proc/kmsg causes internal system calls that are only accessible to the superuser.

There have been several kernel patches proposed ([1], [2], to give just a few examples). Kernel developers have already extensively discussed the topic [3].

The only practical solution I know of is the one implemented by Ubuntu in their klogd init script. They are using a daemonized dd process running as root that forwards messages from /proc/kmsg to the log process:

kmsgpipe=/var/run/klogd/kmsg

...

# create klog-writeable pid and fifo directory mkdir -p /var/run/klogd chown klog:klog /var/run/klogd mkfifo -m 700 $kmsgpipe chown klog:klog $kmsgpipe

# shovel /proc/kmsg to pipe readable by klogd user start-stop-daemon --start --pidfile $kmsgpidfile --exec /bin/dd -b -m -- bs=1 if=/proc/kmsg of=$kmsgpipe

# start klogd as non-root with reading from kmsgpipe start-stop-daemon --start --quiet --chuid klog --exec $binpath -- $KLOGD

I think that this exact solution can be easily ported to syslog-ng.

Starting with syslog-ng OSE/PE 3.0, syslog-ng manages its own capabilities, thus it is able to read /proc/kmsg after switching to another uid. This means that syslog-ng retains the CAP_SYS_ADMIN capability, which is way stronger than it should be, but I guess the kernel part is not going to change. The hack that you mention Ubuntu is doing would work for syslog-ng as well, not very nice from the performance point of view, though. As there are two alternatives for running syslog-ng as non-root, I would not like to add this hack to syslog-ng: 1) run klogd, just as before 2) run syslog-ng 3.0, which manages its own capabilities, with CAP_SYS_ADMIN present in the cap-set /proc/kmsg can be read. -- Bazsi