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: link
Be 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