Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!psuvax1!schwartz@shire.cs.psu.edu From: schwartz@shire.cs.psu.edu (Scott Schwartz) Newsgroups: comp.unix.wizards Subject: Re: descriptors vs pathnames (was Re: getcwd() and friends.) Message-ID: <4468@psuvax1.cs.psu.edu> Date: 13 Apr 89 23:40:29 GMT References: <811@mtxinu.UUCP> <12625@swan.ulowell.edu> <13550@ncoast.ORG> <4457@psuvax1.cs.psu.edu> <1249@ncr-sd.SanDiego.NCR.COM> Sender: news@psuvax1.cs.psu.edu Reply-To: schwartz@shire.cs.psu.edu (Scott Schwartz) Organization: Pennsylvania State University, Computer Science Lines: 66 In-reply-to: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) In article <1249@ncr-sd.SanDiego.NCR.COM>, greg@ncr-sd (Greg Noel) writes: >In article <4457@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu >(Scott Schwartz) writes: >>... what Felix Lee and I are proposing ... is to add two new flags >>to open.... The flags are O_EXEC ... and O_OPEN .... After some thought, I think we actually need three flags: O_EXEC: open for execution O_STAT: open for nothing (e.g. so you can fstat mode 0 files) O_OWNER: open for owner operations (chown, chmod) (I am definately on the lookout for creeping featurism at this point :-) >It's interesting to me how this thread is re-inventing the opaque directory >object proposed as part of the Secure Multics Project. Long past time for me to read Organick, I guess. >The essential point >of your proposal is to be able to acquire a handle on some component of the >file system tree, and then be able to perform operations on it. In other >words, you are decoupling the name lookup from the operation. In a sense, but not exactly. Essentially I want unix to be a capability based system, at least in terms of the filesystem interface. So when you get ahold of a handle on a filesystem object (via a descriptor) you hold both a handle on the object and a set of rights to manipulate it. (You could certainly do it other ways, but I feel this is the right approach because it is the way read and write currently operate, and makes some other things easier.) Enter, unix++. The (somewhat ongoing) project that inspired these proposed modifications was an access-control-list server: a uid 0 process that takes requests for files (the arguments to open, plus some authentication stuff) and returns descriptors. The acl server must decide if it should grant access to each particular file, and how much access it should grant. So I could ask the server for an execute mode descriptor to one of your (mode 700) files, and then execute the file with fexecve. I need enough rights to execute the file, but not so many that I could do anything else with it. Hence the O_EXEC flag. Other operations require more and/or different rights, hence the O_OWNER and O_STAT flags. >The new syscalls should modify the file handle passed it, not create a new >one, so the standard sematics can be easily simulated. >I don't think you need more than the one new syscall (or one new option to >the current open) in order to get the results you want; just consider the >file handle as opaque until it's consumed by another syscall, which has the >power to modify the attributes as necessary. This approach has its attractions. The catch is that I want to localize the "power to modify the attributes". When one process gets an opaque descriptor from another, does it have the right to make these modifications? Also, if open is the only call that can create an instance of access rights (in the form of a file descriptor) then everything is tidy. In particular, I don't need any really new syscalls. Just some cutting and pasting to convince the old ones that they don't need to call namei and check access and all the rest. (Minimizing the extent of the changes I need for this is a factor.) -- Scott Schwartz