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

[Christoph Lameter]

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.

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

> 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?


> If you are nonroot but you have a capability, you can add it to pA.
> If you do so, your children get that capability in pA, pP, and pE.
> For example, you can set pA = CAP_NET_BIND_SERVICE, and your
> children can automatically bind low-numbered ports.  Hallelujah!

I love this solution.

> [2] The libcap capability mask parsers and formatters are
> dangerously misleading and the documentation is flat-out wrong.  fE
> is *not* a mask; it's a single bit.  This has probably confused
> every single person who has tried to use file capabilities.

Hmmm... yes lets clean that up as well. Then your formula makes sense.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/