lkml.org 
[lkml]   [2011]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: CAP_SYSLOG, 2.6.38 and user space
    From
    Date
    On Wed, 2011-02-09 at 13:34 -0800, david@lang.hm 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@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.
    >
    > 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.

    --
    |8]





    \
     
     \ /
      Last update: 2011-02-09 22:43    [W:0.022 / U:29.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site