Re: CAP_SYSLOG, 2.6.38 and user space

[Gergely Nagy <algernon@balabit.hu>]

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@hallyn.com>
> 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@hallyn.com>
> ---
>  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.

-- 
|8]