Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]

[Sebastien Roy]

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