Re: CAP_SYSLOG, 2.6.38 and user space

[Gergely Nagy <algernon@balabit.hu>]

On Thu, 2011-02-03 at 15:32 +0000, Serge E. Hallyn wrote:
> > Back in november, a patch was merged into the kernel (in  commit
> > ce6ada35bdf710d16582cc4869c26722547e6f11), that splits CAP_SYSLOG out of
> > CAP_SYS_ADMIN.
> > 
> > Sadly, this has an unwelcomed consequence, that any userspace syslogd
> > that formerly used CAP_SYS_ADMIN will stop working, unless upgraded, or
> > otherwise adapted to the change.
> > 
> > However, updating userspace isn't that easy, either, if one wants to
> > support multiple kernels with the same userspace binary: pre-2.6.38, one
> > needs CAP_SYS_ADMIN, but later kernels will need CAP_SYS_ADMIN. It would
> > be trivial to keep both, but that kind of defeats the purpose of
> > CAP_SYSLOG,
> 
> The idea would be to only use both when you detect a possibly older
> kernel. 

I was considering that, but... how do I reliably detect an older kernel?

So far, I didn't find a reliable way with which I can detect a kernel
version at run-time (apart from parsing utsname) - but it's entirely
possible, that I missed something obvious.

Furthermore, this still needs an userspace upgrade aswell, so only helps
one half of the problem.

> However, you're right of course, I really should have provided some way
> for userspace to click 'ok, got the message, now continue anyway because
> I'm running older userspace for now,'  i.e. a sysctl perhaps.
> 
> Sorry about the trouble.  Here is a patch to just warn for now, with
> the changelog showing what i intend to push next.
> 
> sorry again,
> -serge
> 
> From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001
> From: Serge Hallyn <serge@peq.(none)>
> Date: Thu, 3 Feb 2011 09:26:15 -0600
> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now
> 
> At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0.  When
> 0, refuse if cap_sys_admin, if 1, then allow.  This will allow
> users to acknowledge (permanently, if they must, using /etc/sysctl.conf)
> that they've seen the syslog message about cap_sys_admin being
> deprecated for syslog.

Could we have it the other way around, at least for a while? Otherwise,
if someone happens to upgrade the kernel, and forgets to upgrade the
syslogd, he'll still experience breakage. With defaulting to 1,
compatiblity is kept, and systems that were upgraded properly can set it
to 0 and live happily ever after. The WARNs should prompt people to
upgrade at the first opportunity, so hopefully, it won't go unnoticed
and ignored by userspace.

I'm not sure one would even see the kernel warn with the syslogd not
being able to read the kernel messages (dmesg, of course, would reveal
it, but that's one extra step).

-- 
|8]