LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com> To: "Serge E. Hallyn" <serge@hallyn.com> Cc: david@lang.hm, Gergely Nagy <algernon@balabit.hu>, James Morris <jmorris@namei.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: CAP_SYSLOG, 2.6.38 and user space Date: Wed, 9 Feb 2011 21:23:29 +0000 [thread overview] Message-ID: <20110209212329.GA24777@mail.hallyn.com> (raw) In-Reply-To: <20110206011831.GB15805@mail.hallyn.com> Quoting Serge E. Hallyn (serge@hallyn.com): > Quoting david@lang.hm (david@lang.hm): > > On Fri, 4 Feb 2011, Serge E. Hallyn wrote: > > > > >Quoting Gergely Nagy (algernon@balabit.hu): > > >>On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote: > > >>>Quoting Serge E. Hallyn (serge@hallyn.com): > > >>>>>From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > > >>>>From: Serge Hallyn <serge@peq.(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@hallyn.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@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(-) 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
next prev parent reply other threads:[~2011-02-09 21:22 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-02-03 11:39 CAP_SYSLOG, 2.6.38 and user space Gergely Nagy 2011-02-03 15:13 ` Alan Cox 2011-02-03 15:32 ` Serge E. Hallyn 2011-02-03 15:53 ` Gergely Nagy 2011-02-03 16:51 ` Serge E. Hallyn 2011-02-03 17:07 ` Gergely Nagy 2011-02-04 0:49 ` david 2011-02-04 8:03 ` Marc Koschewski 2011-02-04 8:40 ` Gergely Nagy 2011-02-04 11:08 ` Alan Cox 2011-02-04 16:03 ` Serge E. Hallyn 2011-02-03 15:54 ` Nick Bowler 2011-02-04 16:05 ` Serge E. Hallyn 2011-02-04 16:33 ` Gergely Nagy 2011-02-04 17:15 ` Serge E. Hallyn 2011-02-05 7:05 ` david 2011-02-06 1:18 ` Serge E. Hallyn 2011-02-09 21:23 ` Serge E. Hallyn [this message] 2011-02-09 21:28 ` Gergely Nagy 2011-02-09 21:34 ` david 2011-02-09 21:40 ` Gergely Nagy 2011-02-09 21:47 ` david 2011-02-09 22:04 ` Gergely Nagy 2011-02-09 22:27 ` david 2011-02-09 22:37 ` Gergely Nagy 2011-02-10 14:29 ` Serge E. Hallyn 2011-02-09 19:50 ` Gergely Nagy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110209212329.GA24777@mail.hallyn.com \ --to=serge@hallyn.com \ --cc=algernon@balabit.hu \ --cc=david@lang.hm \ --cc=jmorris@namei.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).