On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote: >> On 07/12/2017 05:38 PM, Paul Moore wrote: >> > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@xxxxxxxxxxxxx >> > > wrote: >> > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote: >> > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@xxxxxxxxx >> > > > .gov> >> > > > wrote: >> > While I think splitting the NNP/nosuid transition restrictions >> > might >> > be a good idea under the new policy capability, I'm not sure it is >> > worth the cost of a "process2" object class. >> > >> > With that in mind, let's do two things with this patch: >> > >> > * Mention the nosuid restrictions in the patch description. It >> > doesn't need much text, but something would be good so we have >> > documentation in the git log. >> > >> > * Let's pick a new permission name that is not specific to NNP or >> > nosuid. IMHO, nnpnosuid_transition is ... less than good. >> > Unfortunately, I'm not sure I'm much better at picking names; how >> > about "protected_transition"? "restricted_transition"? >> > "enable_transition"? "override_transition"? >> >> I vote for nnp_transition anyway. "No New Privileges" encompasses >> nosuid in my mind. If the two perms had been separated I would have >> been inclined to allow both every time one of them was needed, to >> make >> sure no one was surprised by the behavior difference. > > I agree; I'll keep it as nnp_transition and just document it in the > patch description. Sorry to be a stubborn about this, but nnp_transition makes little sense for the nosuid restriction. Like it or not, NNP has a concrete meaning which is distinct from nosuid mounts. We don't have to pick any of the permission names I tossed out, none of those were very good, but I would like to see something that takes both NNP and nosuid into account, or preferably something that doesn't use either name explicitly but still conveys the meaning. -- paul moore www.paul-moore.com
