Date:	Thu, 3 Feb 2011 16:51:32 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Gergely Nagy <algernon@...abit.hu>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>
Subject: Re: CAP_SYSLOG, 2.6.38 and user space

Quoting Gergely Nagy (algernon@...abit.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)

...  Why not parse 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.

True, that only addresses the less forgivable problem I introduced, namely
what does updated userspace even do to do the right thing.

> > 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@....(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,

Sure.

So long as there is a definite path toward eventually having syslog
with CAP_SYS_ADMIN be denied.

> 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).

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists