On Fri, 2009-07-03 at 16:32 +0200, Casper.Dik at Sun.COM wrote:
> >On Fri, 2009-07-03 at 05:45 -0700, Casper Dik wrote:
> >I have no problem with these new privileges, but do have one question
> >regarding the semantics of adding them to the basic set. How will this
> >affect processes that may be specifying individual privileges in the
> >"basic" set by enumeration rather than specifying "basic" itself in the
> >various APIs? Will they cease to be able to read and write files? Do
> >such applications exist?
>
> When define a "set of privileges", you must start with the basic set.
> This is how the basic set is defined. The basic set is extensible.
Okay.
> Perhaps we need to force that in SMF and in user_attr. Within Solaris, I
> found only one manifest which listed needed privileges but it has recently
> been fixed.
Right; SMF manifests is one area that I was thinking where this could
have been a problem. Another is applications that might be doing this
kind of thing:
1. application starts with all kinds of privileges including basic
2. application needs to fork a child that only needs to read and write
to files it owns
3. application calls fork, and then in the child calls setppriv() with
the empty set assuming that it needs no privileges to read and write
files that it owns
I think these (if they exist) will break. I know I have one of these in
my project gate that I'll have to fix. ;-)
> The private interfaces __init_daemon_priv and __init_suid_priv will
> always add the basic set.
>
> The only time when we actually set a limit set to {empty} is by setting
> the limit set but we only do that when we do not expect any execve calls.
Right; like the above example.
-Seb
