All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maximilian Attems <max@stro.at>
To: Mike Waychison <mikew@google.com>
Cc: "Andrew G. Morgan" <agm@google.com>,
	Eric Northup <digitaleric@google.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Eric Paris <eparis@parisplace.org>,
	klibc@zytor.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] run-init: Add drop_capabilities support.
Date: Tue, 2 Aug 2011 23:09:12 +0200	[thread overview]
Message-ID: <20110802210912.GB20986@stro.at> (raw)
In-Reply-To: <CAGTjWtCYb0NOBFsMxWKWEwN-pdOD1fqimHco3nk_N-tKQvxdyQ@mail.gmail.com>

On Fri, 29 Jul 2011, Mike Waychison wrote:

> On Fri, Jul 29, 2011 at 1:45 PM, Maximilian Attems <max@stro.at> wrote:
> > On Tue, 19 Jul 2011, Mike Waychison wrote:
> >
> >> This patch adds the ability to run-init to allow the dropping of
> >> POSIX capabilities.
> >>
> >> This works by adding a "-d" flag to run-init, which takes a comma
> >> separated list of capability names that should be dropped right before
> >> exec'ing the real init binary.
> >>
> >> kinit is also modified by this change, such that it understands the same
> >> argument when prepended with "drop_capabilities=" on the kernel command
> >> line.
> >>
> >> When processing capabilities to drop, CAP_SETPCAP is special cased to be
> >> dropped last, so that the order that capabilities are given does not
> >> cause dropping of later enumerated capabilities to fail if it is listed
> >> early on.
> >>
> >> Dropping of capabilities happens in three parts.  We explicitly drop the
> >> capability from init's inherited, permitted and effective masks.  We
> >> also drop the capability from the bounding set using PR_CAPBSET_DROP.
> >> Lastly, if available, we drop the capabilities from the bset and
> >> inheritted masks exposed at /proc/sys/kernel/usermodehelper if available
> >> (introduced in v3.0.0).
> >
> > hmm as 3.0 is out, I don't think we need more backward compatibility.
> > do you have a strong arg for it?
> > especially since this is an *optional* calling arg I really don't see
> > the need of that backward crap.
> 
> I'd like to keep it for the time being. I'm still building both 2.6.34
> and 2.6.39 kernels at the moment, though I can maintain these last few
> compatibility bits in-house if that makes it easier for you.

you include anyway linux/version.h, would build disabling help you?
that way that macro doesn't need duplicating.

  reply	other threads:[~2011-08-02 21:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-19 20:38 [PATCH v1 0/2] Support dropping of capabilities from early userspace Mike Waychison
2011-07-19 20:38 ` [PATCH v1 1/2] syscalls: Add capset and capget Mike Waychison
2011-07-29 20:41   ` Maximilian Attems
2011-07-29 23:06   ` Maximilian Attems
2011-07-19 20:38 ` [PATCH v1 2/2] run-init: Add drop_capabilities support Mike Waychison
2011-07-29 20:45   ` Maximilian Attems
2011-07-29 20:46     ` Mike Waychison
2011-08-02 21:09       ` Maximilian Attems [this message]
2011-08-02 21:42         ` Mike Waychison
2011-08-02 22:50           ` Andrew G. Morgan
2011-08-02 22:56             ` Mike Waychison
2011-08-02 23:37               ` Mike Waychison
2011-08-03  0:48                 ` H. Peter Anvin

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=20110802210912.GB20986@stro.at \
    --to=max@stro.at \
    --cc=agm@google.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=digitaleric@google.com \
    --cc=eparis@parisplace.org \
    --cc=hpa@zytor.com \
    --cc=klibc@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.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.