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


  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;
as well as URLs for NNTP newsgroup(s).