[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110209212329.GA24777@mail.hallyn.com>
Date: Wed, 9 Feb 2011 21:23:29 +0000
From: "Serge E. Hallyn" <serge@...lyn.com>
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: david@...g.hm, Gergely Nagy <algernon@...abit.hu>,
James Morris <jmorris@...ei.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: CAP_SYSLOG, 2.6.38 and user space
Quoting Serge E. Hallyn (serge@...lyn.com):
> Quoting david@...g.hm (david@...g.hm):
> > On Fri, 4 Feb 2011, Serge E. Hallyn wrote:
> >
> > >Quoting Gergely Nagy (algernon@...abit.hu):
> > >>On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote:
> > >>>Quoting Serge E. Hallyn (serge@...lyn.com):
> > >>>>>From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001
> > >>>>From: Serge Hallyn <serge@....(none)>
> > >>>>
> > >>>>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.
> > >>>>
> > >>>>Signed-off-by: Serge Hallyn <serge@...lyn.com>
> > >- goto warn; /* switch to return -EPERM after 2.6.39 */
> > >+ !capable(CAP_SYSLOG)) {
> > >+ /* remove after 2.6.39 */
> > >+ if (capable(CAP_SYS_ADMIN))
> > >+ WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN "
> > >+ "but no CAP_SYSLOG (deprecated).\n");
> > >+ else
> > >+ return -EPERM;
> > >+ }
> > > }
> >
> > why does this need to be removed after 2.6.39?
> >
> > whenever you go to remove it you will break userspace, what's the
> > benifit of breaking userspace?
> >
> > I can understand that it's better to have a syslog daemon with
> > CAP_SYSLOG instead of CAP_SYS_ADMIN, but does "it would be better to
> > have userspace changed" really translate into "it's so important to
> > have userspace changed that we need to break any userspace that
> > hasn't changed"?
> >
> > I really don't think so.
>
> I think I agree with you. If someone wants to grant one of the other
> CAP_SYS_ADMIN powers without CAP_SYSLOG, then they can break that into
> yet another, i.e. CAP_IPCSET. Makes sense.
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@...lyn.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@...lyn.com>
---
kernel/printk.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 2ddbdc7..ff58136 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -274,12 +274,12 @@ int do_syslog(int type, char __user *buf, int len, bool from_file)
* at open time.
*/
if (type == SYSLOG_ACTION_OPEN || !from_file) {
- if (dmesg_restrict && !capable(CAP_SYSLOG))
- goto warn; /* switch to return -EPERM after 2.6.39 */
+ if (dmesg_restrict && !capable(CAP_SYSLOG) && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
if ((type != SYSLOG_ACTION_READ_ALL &&
type != SYSLOG_ACTION_SIZE_BUFFER) &&
- !capable(CAP_SYSLOG))
- goto warn; /* switch to return -EPERM after 2.6.39 */
+ !capable(CAP_SYSLOG) && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
}
error = security_syslog(type);
@@ -423,12 +423,6 @@ int do_syslog(int type, char __user *buf, int len, bool from_file)
}
out:
return error;
-warn:
- /* remove after 2.6.39 */
- if (capable(CAP_SYS_ADMIN))
- WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN "
- "but no CAP_SYSLOG (deprecated and denied).\n");
- return -EPERM;
}
SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len)
--
1.7.2.3
--
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