>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. ;-)
Yeah, I guess you didn't follow the guidelines but if they are not
spelled out then we need to fix the documentation.
Perhaps it's hidden too well, but there are such bits as:
To maintain future compatibility, the "basic" set of
privileges is included as "basic,!missing_basic_priv1,...".
When further currently unprivileged operations migrate to
the basic privilege set, the conversion back of the result
with priv_str_to_set() includes the additional basic
privileges, guaranteeing that the resulting privilege set
carries the same privileges. This behavior is the default
and is equivalent to specifying a flag argument of
PRIV_STR_PORT.
Casper
