From: Gergely Nagy <algernon@balabit.hu>
To: Marc Koschewski <marc@osknowledge.org>
Cc: david@lang.hm, "Serge E. Hallyn" <serge@hallyn.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
James Morris <jmorris@namei.org>
Subject: Re: CAP_SYSLOG, 2.6.38 and user space
Date: Fri, 04 Feb 2011 09:40:04 +0100 [thread overview]
Message-ID: <1296808804.24742.6.camel@moria> (raw)
In-Reply-To: <20110204080302.GA24941@marc.osknowledge.org>
On Fri, 2011-02-04 at 09:03 +0100, Marc Koschewski wrote:
> Moreover, this change really is 'hell' on _many_ machines. We had discussed a
> thousands time to not break existing applications. So a) either make it optional in
> the kernel so that userspace still works with CAP_SYS_ADMIN _and_ CAP_SYSLOG
> while dropping a note that it should be fixed in userspace _and_ mark it as
> deprecated as of mid 2012 or b) revert it.
I think the sysctl method would be superior, because it places the
migration time in the hands of the distributions/admins, and gives
syslogds a way to adjust, and use either CAP_SYS_ADMIN or CAP_SYSLOG,
based on the presence of the sysctl setting (as opposed to using either
and just postponing the flag-day from 2.6.38 to mid 2012, where we'd
have the same issues we have now: unupgraded userspace breaking).
Having both CAP_SYS_ADMIN and CAP_SYSLOG at the same time, for the sole
purpose of reading kernel log messages would kind of defeat the purpose
of CAP_SYSLOG. Therefore, a solution that allows both at the same time
doesn't look all that good to me.
However, having it toggle-able does, and solves all my worries at least:
defaulting to CAP_SYS_ADMIN maintains backwards compatibility, upgraded
systems can switch to CAP_SYSLOG if and when the system is ready for
that. All's well!
--
|8]
next prev parent reply other threads:[~2011-02-04 8:40 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 [this message]
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
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=1296808804.24742.6.camel@moria \
--to=algernon@balabit.hu \
--cc=david@lang.hm \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc@osknowledge.org \
--cc=serge@hallyn.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.