On Tuesday, October 31, 2006 04:54:33 AM -0800 "Darren J. Moffat" <Darren.Moffat at Sun.COM> wrote:
> Since nobody has replied we are going to have to assume this design is > perfect and is ready to go to PSARC for review. > > If anyone wants to review it before we take it to PSARC please speak now. Heh. Like that ever works. :-) I have read the design, and overall it looks good to me. I don't particularly care for the naming scheme proposed for the new privileges; the normal case is for a process to be neither privileged nor anonymous, and the names should reflect that -- instead of distinguishing privileges that apply to "normal" processes with names like FILE_NANON_READ, I'd distinguish privileges that apply to anonymous proceses with names like FILE_ANON_READ. But that's a pretty minor issue. I do have some issues with the proposed behavior for file and directory creation. First, tying these operations to those requiring ownership of an existing object seems inappropriate. Creating a filesystem object does not require ownership of any existing object, and so should not require any form of "act-as-owner" privilege. However, it would seem to make sense to add separate FILE_NANON_CREATE and FILE_GEN_CREATE privileges, which would affect the ability to create objects in a directory in the same way that FILE_NANON_WRITE and FILE_GEN_WRITE affect the ability to write to a file (so, if you have FILE_GEN_CREATE but not FILE_NANON_CREATE, you can create files only in world-writable directories; if you have neither, you don't get to create anything). I also don't see the "privilege escalation" attack that is supposedly solved by not permitting a process to create a file or directory to which it would then have no access. In fact, several existing filesystems have the concept of a "dropbox" directory, in which some users/clients can create new files but not see or access existing files. To pick a somewhat contrived example, this would seem a useful behavior for a mail or print spool submitter, which may need to create new spool files but will never need to examine the contents of existing ones. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
