Re: CAP_SYSLOG, 2.6.38 and user space

[Gergely Nagy]

On Wed, 2011-02-09 at 13:47 -0800, david@xxxxxxx wrote: 
> On Wed, 9 Feb 2011, Gergely Nagy wrote:
> 
> > On Wed, 2011-02-09 at 13:34 -0800, david@xxxxxxx wrote:
> >> On Wed, 9 Feb 2011, Gergely Nagy wrote:
> >>
> >>> 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.
> >>
> >> what is your justification for ever having CAP_SYS_ADMIN return -EPERM?
> >> what's the value in blocking this.
> >
> > Nothing. Come to think of it, the main use of the sysctl would be to
> > detect CAP_SYSLOG support, so that applications can drop CAP_SYS_ADMIN
> > and use CAP_SYSLOG only (which, imo, is a good idea - the less
> > capabilities, the better, and CAP_SYS_ADMIN is quite broad when one only
> > wants CAP_SYSLOG).
> >
> > If there's a better way to allow userspace to easily detect CAP_SYSLOG,
> > I'm all for that.
> 
> if userspace wants to detect this, what is wrong with them checking for a 
> kernel >= 2.6.38?

How do I do that, apart from parsing utsname, which I find insultingly
ugly? It might be just me, but I very much prefer feature tests over
version sniffing.

> realistically, if the upstream applications (which need to work with many 
> different versions) just support having CAP_SYS_ADMIN, it would be a very 
> minor distro patch to change this to CAP_SYSLOG for a distro release where 
> the distro _knows_ that they don't have to support an older kernel.

That is, indeed, true, and works for distros. But when a software vendor
provides binaries aswell as source, they do have to support older
kernels too. And even if that is possible with CAP_SYS_ADMIN, I'd still
prefer CAP_SYSLOG, if available.

Thus, being able to easily adapt is something I'm very interested in. If
that's not possible, using CAP_SYS_ADMIN for a long long time still is
the second best option.

I also wish to place as little burden on distros as possible, so
delegating the decision to them does not appeal to me that much. It's
certainly an option, but I'm sure we can do better than that.

-- 
|8]



--
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/