Quoting Andrew G. Morgan ([EMAIL PROTECTED]): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -long cap_prctl_drop(unsigned long cap) > +static long cap_prctl_drop(unsigned long cap) > ~ { > - - if (!capable(CAP_SETPCAP)) > + if (cap_capable(current, CAP_SETPCAP) != 0) > > | With this change, you > > | a) prevent PF_SUPERPRIV being set, although the task did > | explicitly attempt a privileged operation. > > | b) stop checking other security modules, so for instance > | selinux no longer gets a say in dropping of > | capabilities. > > | Are these both intended? > > No. They were an oversight while I was trimming the patch. Good catch! > > + default: > + /* No functionality available - continue with default */ > + return 0; > > | Hmm, if CONFIG_SECURITY_FILE_CAPABILITIES=n and cmd is one of the above > | like PR_CAPBSET_DROP, do we want to return 0 and allow someone else to > | handle these, or is it more appropriate to return -EINVAL? > > My feeling was that if this functionality is not configured, then I > didn't want to alter legacy expectations. > > I very much wanted to limit this change to affect only those brave souls > willing to use the "experimental" filesystem support for capabilities.
Ok - there's no LSM that I know of right now that would try to hijack these anyway :) thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html