Re: CAP_SYSLOG, 2.6.38 and user space

From: Serge E. Hallyn
Date: Thu Feb 10 2011 - 09:28:49 EST


Quoting Gergely Nagy (algernon@xxxxxxxxxx):
> On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote:
> > So if that's how we're leaning, then the following patch is much more
> > concise. I'll send this to Linus and any appropriate -stable tomorrow
> > if noone objects.
> >
> > From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001
> > From: Serge Hallyn <serge@xxxxxxxxxx>
> > Date: Thu, 3 Feb 2011 09:26:15 -0600
> > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2)
> >
> > It'd be nice to do that later, but it's not strictly necessary,
> > and it'll be hard to do without breaking somebody's userspace.
> >
> > Signed-off-by: Serge Hallyn <serge@xxxxxxxxxx>
> > ---
> > kernel/printk.c | 14 ++++----------
> > 1 files changed, 4 insertions(+), 10 deletions(-)
>
> Personally, I'd prefer the sysctl idea in the long run, because
> userspace can easily and automatically adapt to the running kernel then.
> Ie, this patch is fine for 2.6.38, but later on, a sysctl could be
> introduced, that when set (but defaulting to unset, as to not break
> userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds
> could look at the setting, and act accordingly. This would mean that old
> userspace wouldn't break, and upgraded userspace could work on both old
> and new kernels, depending on the setting. Distros or admins could then
> enable the sysctl once they made sure that all neccessary applications
> have been upgraded.
>
> But this works too, for now. My immediate concern is making sure 2.6.38
> doesn't break capability-using syslogds.

Ok, I'll forward the previous patch.

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