Re: [PATCH v2 1/2] capabilities: Ambient capabilities

On Mon, May 18, 2015 at 12:43 PM, Andy Lutomirski [off-list ref] wrote:

On May 15, 2015 11:31 PM, "Christoph Lameter" [off-list ref] wrote:

quoted

It would be best to start a complete new thread about this. You
replied to earlier posts about ambient capabilities and
people may not see it as a new release.

quoted

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.  Because capability

Ok that is a good improvement.

quoted

inheritance is so broken, setting KEEPCAPS, using setresuid to
switch to nonroot uids, or calling execve effectively drops
capabilities.  Therefore, setresuid from root to nonroot
conditionally clears pA unless SECBIT_NO_SETUID_FIXUP is set.
Processes that don't like this can re-add bits to pA afterwards.

The capability evolution rules are changed:

  pA' = (file caps or setuid or setgid ? 0 : pA)
  pP' = (X & fP) | (pI & fI) | pA'
  pI' = pI
  pE' = (fE ? pP' : pA')

Isnt this equal to

    pE' = (fE & pP') | pA'

which does not require conditionals and is symmetric to how pP' is
calculated. Your formula seems to indicate that pA' bits are not set if
fE is set. However they are already set unconditionally in pP' regardless.
This makes it more explicit I think. And I thought we are dealing with
bitmask arithmetic here?

I think you're right, except that fE is a Boolean, not a bit mask, so
fE | pP' is an odd thing to talk about.

We could say (fE ? pP' : 0) | pA', which could simplify the code a tiny bit.

It turns out that would be almost a pure addition of code, so I'll
leave it as is.

--Andy