Util-Linux package development
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Andy Lutomirski <luto@kernel.org>
Cc: util-linux@vger.kernel.org, Karel Zak <kzak@redhat.com>
Subject: Re: [PATCH 5/5] setpriv: support modifying the set of ambient capabilities
Date: Sun, 25 Jun 2017 11:33:58 +0200	[thread overview]
Message-ID: <20170625093358.GB981@pks-xps> (raw)
In-Reply-To: <CALCETrUe4-Tv=i7tAkdnKmEZtU76UA2vOWuBYmQsspobinjGpg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

On Sat, Jun 24, 2017 at 01:47:29PM -0700, Andy Lutomirski wrote:
> On Sat, Jun 24, 2017 at 7:04 AM, Patrick Steinhardt <ps@pks.im> wrote:
> > Right now, we do not support modifying the set of ambient capabilities,
> > which has been introduced quite recently with Linux 4.3. As libcap-ng
> > does not yet provide any ability to modify this set, we do have to roll
> > our own support via `prctl`, which is now easy to do due to the
> > indirections introduced in the preceding commits. We add a new command
> > line argument "--ambient-caps", which uses the same syntax as both
> > "--inh-caps" and "--bounding-set" to specify either adding or dropping
> > capabilities.
> >
> > This commit also adjusts documentation to mention the newly introduced
> > ability to modify the ambient capability set.
> >
> 
> One question here: should requesting an ambient cap also implicitly
> put it in the inheritable set, at least if --inh-caps isn't specified?

Good question. By itself, it doesn't make any sense to have an
ambient capability without having it set in the inheratibale
capabilities, as otherwise the ambient capability wouldn't be
granted at all. This is due to the invariant (quoting from your
message at [1]):

    pA obeys the invariant that no bit can ever be set in pA if
    it is not set in both pP and pI. Dropping a bit from pP or pI
    drops that bit from pA. This ensures that existing programs
    that try to drop capabilities still do so, with a
    complication.

With pA being ambient capabilities, pP being the permitted
capabilities and pI being inheritable capabilities.

But given that you were being conservative here, we should
probably err on the conservative side, as well. Meaning we force
the user to be explicit and not automatically set the inheritable
capability.

[1]: https://lwn.net/Articles/636533/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-06-25  9:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-24 14:04 [PATCH 0/5] Ambient capabilities for setpriv Patrick Steinhardt
2017-06-24 14:04 ` [PATCH 1/5] setpriv: introduce indirection for `capng_type` enum Patrick Steinhardt
2017-06-24 14:04   ` [PATCH 2/5] setpriv: proxy function checking whether a capability is set Patrick Steinhardt
2017-06-24 20:44     ` Andy Lutomirski
2017-06-24 14:04   ` [PATCH 3/5] setpriv: proxy function to update capabilities Patrick Steinhardt
2017-06-24 20:45     ` Andy Lutomirski
2017-06-24 14:04   ` [PATCH 4/5] setpriv: support dumping ambient capabilities Patrick Steinhardt
2017-06-24 20:46     ` Andy Lutomirski
2017-06-24 14:04   ` [PATCH 5/5] setpriv: support modifying the set of " Patrick Steinhardt
2017-06-24 20:47     ` Andy Lutomirski
2017-06-25  9:33       ` Patrick Steinhardt [this message]
2017-06-24 20:44   ` [PATCH 1/5] setpriv: introduce indirection for `capng_type` enum Andy Lutomirski
2017-06-24 20:43 ` [PATCH 0/5] Ambient capabilities for setpriv Andy Lutomirski
2017-06-25  9:11   ` Patrick Steinhardt
2017-06-27 13:14 ` Karel Zak
2017-06-27 16:00   ` Patrick Steinhardt

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=20170625093358.GB981@pks-xps \
    --to=ps@pks.im \
    --cc=kzak@redhat.com \
    --cc=luto@kernel.org \
    --cc=util-linux@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