validity test in cap_set_proc(), POSIX.1e 25.4.15.2

Casey Schaufler casey at sgi.com
Wed Dec 5 17:35:20 GMT 2001


Robert Watson wrote:
> 
> POSIX.1e D17 25.4.15.2 reads:
> 
>   The function cap_set_proc() shall set the values for all capability
>   flags for all capabilities defined in the implementation with the
>   capability state identified by cap_p.  The new capability state of the
>   process shall be completely determined by the contents of cap_p upon
>   successful return from this function.  If any flag in cap_p is set for
>   any capability not currently permitted for the calling process, the
>   function shall fail, and the capability state of the process shall
>   remain unchanged.
> 
> In our currently implementation, we impose an additional check on cap_p
> provided to cap_set_proc(): we require that the resulting capability set
> be "valid" in the sense that the new effective capabilities be a subset of
> the new permitted capabilities.  Does anyone else take this reading, and
> if not, is there a good reason not to?

You may wish to have a case where you need an effective capability
to do an exec(), perhaps CAP_DAC_OVERRIDE, but explicitly don't
want it in the permitted set of the resulting program. In this
case you would raise CAP_DAC_OVERRIDE to effective, and clear it
from permitted. You can't clear the permitted set while leaving
any effective in your scheme.

I haven't spent the time required to follow through the
capability recalculation calculus to verify this as an
important case, but it could be.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey at sgi.com				voice: 650.933.1634
casey_p at pager.sgi.com			Pager: 888.220.0607

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message



More information about the posix1e mailing list