>
>Yes, world readable/writable files can still be accessed by dropping =
>the new privileges. One reason are library calls that need to read so=
>me public files (like things in /etc). The need to manipulate or remo=
>ve world writable files is harder to justify, on the other hand, worl=
>d writable files are hard to find.
>
>One may define two additional basic privileges (say PRIV_FILE_ALLOW_{=
>WRITE|READ}) that would be checked first, but so, we have two further=
> privileges 8-)=20Perhaps the outcome of the discussion is that we really only need two. Certainly I think that the design needs to be approached from the proper end: implement a prototype and then see what the effects are of removing the privileges from processes and see whether that is actually useful. To me, a "PRIV_OBJECT_MODIFY" which is required for any file modifying operation would seem to be more useful as often a read-only user is a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS in case you want to prevent any reading. I'm not sure what the distinction of not being able to read the files you own buys you. Certainly the awkward wording including euid/egid and supplemental groups should be changed into something which more clearly expresses the intent: "privilege required for non-anonymous access" Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
