Re: prompt expansion and POSIX.1e capabilities

[Zefram <zefram@fysh.org>]

Clint Adams wrote:
>This is not useful behavior, because (at least on my installation),
>normal users have all capabilities but cap_setpcap raised inheritable.
>This gives me a # prompt, not %, when I log in.

Curious.  At the time I added the POSIX.1e stuff -- the same time I was
working on the Linux kernel POSIX.1e project -- the Inheritable set was
constrained to always be a subset of Permitted.  Also, normal binaries,
having empty file capability sets, would lose all capabilities of their
parents on startup.

It appears that the capability rules have changed, and Inheritable is
no longer required to be a subset of Permitted.  Instead, it's a set
of latent capabilities, that a binary can acquire for real if it has a
non-empty file Inheritable set.

As I noted at the time, the rules about the different capability sets are
too complicated, and I can't tell, just from the code, what administrative
function the Inheritable set fulfills.  My best guess is that it's a
mechanism for implementing decisions about which users are permitted
to invoke which administrative programs, though a rather poor one --
difficult to justify putting into the kernel.

It appears that the best logic to implement is, as you suggest, to
generate the "#" prompt iff the Effective set is non-empty.  Another
possibility is to check both the Effective and Permitted sets; the
Permitted set is effectively `saved capabilities', with similar semantics
to saved UIDs.  However, the non-capability logic doesn't look for a saved
root UID, so I think we should not be looking for Permitted capabilities.

-zefram