Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance without disabling file caps

[Will Drewry <redpig@dataspill.org>]

On Mon, Aug 17, 2009 at 10:26 AM, Andrew G. Morgan<morgan@kernel.org> wrote:
> On Mon, Aug 17, 2009 at 7:38 AM, Will Drewry<redpig@dataspill.org> wrote:
[snip]
>> It is almost possible to achieve #2 on existing systems, assuming xattr
>> support can always be achieved.
>> Step 1, setcap cap_sys_rawio+i /usr/bin/pulseaudio
>> Step 2, pam_cap at X11 login to add cap_sys_rawio+i for a user session
>> (alternately, use capsh).
>> Step 3, run pulseaudio (pP' = (...) | (fI & pI) => cap_sys_rawio+ip)
>
> What about filecaps of cap_sys_rawio+eip on pulseaudio. With the
> bounding set suppressing cap_sys_rawio?
>
> In this case, only a process with (pI & cap_sys_rawio) can exec()ute
> pulseaudio, let alone use the capability. That is, the filecap +pe
> implies that the capability is required for the app to run, but the
> bounding set suppresses the bit from the file's xattr...! The only way
> that the exec()d program can get this required bit is from the (pI &
> fI), and so only if a process has (pI & cap_sys_rawio) will it be able
> to invoke the program...

Aha! I was missing something.  I was thinking that the bounding set was
still governing system-wide despite the fact it was right in front of me
that it wasn't (kernel source, capsh).

This works perfectly and achieves the exact same goal of step-down root
permissions with run-time inheritance-based management.

I guess we can bin the patch since I doubt xattr-less filesystems are
worth the change. (I might whip up a stackable one just to avoid dealing
with symlinks and loopbacks :)

Thanks for working through this with me.  Sorry that it took a few
rounds.

cheers!
will