[Bug 2833] The code in opennsd-compat/port-solaris.c should not change PRIV_LIMIT when PRIV_XPOLICY is set.

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2833

Peter Whittaker <pww at edgekeep.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pww at edgekeep.com

--- Comment #6 from Peter Whittaker <pww at edgekeep.com> ---
The end-goal is to set effective privileges for the current process
(and, to be safe, for any children) but changes to PRIV_LIMIT are not
put into effect until an exec(); refer to "man setppriv" referenced
above: Changing PRIV_LIMIT does nothing to the current process, only to
its children.

The other thing to note from that man page is that when privileges are
removed from PRIV_PERMITTED, they are ALSO immediately and silently
removed from PRIV_EFFECTIVE: if npset is more restrictive than
PRIV_PERMITTED, the first call to setppriv() removes privileges from
both PRIV_PERMITTED and PRIV_EFFECTIVE, which has the desired effect of
removing privileges from the current process.

If npset is more restrictive that PRIV_INHERITABLE, the second call to
setppriv() removes permissions from that set, covering any subsequent
processes created with exec().

Since the privileges of the current process were limited to
PRIV_INHERITABLE when it was exec()'d, if npset is more restrictive
than PRIV_INHERITABLE it is likely more restrictive than PRIV_PERMITTED
- but the reverse might not be true in general, since PRIV_PERMITTED
might have already been reduced to less than PRIV_INHERITABLE.

The end result of these two calls is that PRIV_INHERITABLE and
PRIV_PERMITTED match npset, controlling both the privileges available
to the current process and the privileges available to any children.

Modifying PRIV_LIMIT is redundant and unnecessary. I don't know that it
is harmful (would we ever want to query it?) but it is unneeded.

Refer also to
https://docs.oracle.com/cd/E86824_01/html/E54776/privileges-5.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.