On Thursday 22 June 2006 16:55, you wrote:
> >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-)=20
>
> Perhaps the outcome of the discussion is that we really only need
> two.Okay, one vote for only two privileges. > > 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. So you are in favour of a general turn file acces/manipulation on/off switch. > I'm not sure what the distinction of not being able to read the files > you own buys you. Imagine a process that is started by an ordinary user with the only intent to react on IPC and perhaps read some files in /etc/, /var or other public readable objects (like files in its home directory with sufficient permission bits for everyone) from time to time. In this case, you may drop PRIV_OBJECT_MODIFY, but not PRIV_OBJECT_ACCESS. An exploit of the process may spy out files that may only be read by the user but not by everyone. Other example where you benefit from accessing public but not your own files may be for server side scripting applications of different users that share the same account, automated benchmark suites, hosting of programming competitions, hosted computation software, evaluation of programming exercises of students, ... You may read about further examples in my technical report "Secure execution of untrusted code" (unfortunately only in German) on http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_09_Sichereausfuehrung.pdf > > 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 Totally agree with you. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
