On Fri, 2009-07-03 at 16:43 +0200, Casper.Dik at Sun.COM wrote: > > >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.
Indeed, the documentation could be more explicit. Thanks for the clarifications. +1 on this case. -Seb
