schwartz@shire.cs.psu.edu (Scott Schwartz) (04/11/89)
In article <13550@ncoast.ORG>, allbery@ncoast (Brandon S. Allbery) writes: > fd = open(".", 0); > chdir("/tmp"); > ...do something... > ...root makes /usr/spool mode 0700 owner bin... > fchdir(fd); <-- succeeds > chdir("/tmp"); > ...do something... > ...root changes permissions as above... > chdir("/usr/spool/uucppublic"); <-- FAILS! >There is a distinction. The permissions on a file are dependent on the >permissions of each component of the path; Ok, but suppose we do add the new functionality to unix. Is that a mistake? Is the functionality in your example undesirable, or just new? I mean, once you aquire a file descriptor for a directory (or file) you can read that directory (or file) even if it's permissions change, right? So why not permit the process' current directory to be set via the descriptor as well? By the way, lest things become confused, what Felix Lee and I are proposing (at this point) is to add two new flags to open, and some new syscalls. The flags are O_EXEC, which opens for execution (used with fexec, fchdir), and O_OPEN, which opens for nothing in particular (used with fchmod, fchown). So the example above would use fd = open (".", O_EXEC); SunOS implements fchdir, and requires that you have search permission on the directory at the time of the fchdir call. Is this the right thing to do (assuming you have the O_EXEC flag, which SunOS doesn't)? Given that the user has the directory open for execution, is there any reason to check access again during the fchdir? -- Scott Schwartz <schwartz@shire.cs.psu.edu>
peter@ficc.uu.net (Peter da Silva) (04/12/89)
In article <4457@psuvax1.cs.psu.edu>, schwartz@shire.cs.psu.edu (Scott Schwartz) writes: > By the way, lest things become confused, what Felix Lee and I are > proposing (at this point) is to add two new flags to open, and some > new syscalls. The flags are O_EXEC, which opens for execution (used > with fexec, fchdir), and O_OPEN, which opens for nothing in particular > (used with fchmod, fchown). Why do you need an O_EXEC? I can see it would be desirable to know that you can exec the file you have O_OPENned, but it's not necessary. It also complicated the design. Why not have an O_CHOWN (only succeeds if owner or superuser), O_CHMOD, etc...? O_OPEN by itself will serve. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (04/13/89)
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 .... It's interesting to me how this thread is re-inventing the opaque directory object proposed as part of the Secure Multics Project. 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. The points you are mooting have to do with the semantics of name lookup; you should focus your effor there. So what you need is a syscall that allows you to convert a textual name into an opaque file handle; for the sake of discussion (no matter how it's actually implemented), let's call it namei(). Thus, namei("/usr/tmp/foo") produces a file handle for a (potentially non-existant?) file; then most of the current system call that take a name could be defined in terms of this new call. (creat(filename, mode) would be fcreate(namei(filename, mode)).) 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. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
schwartz@shire.cs.psu.edu (Scott Schwartz) (04/14/89)
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 <schwartz@shire.cs.psu.edu>
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (04/18/89)
In article <1249@ncr-sd.SanDiego.NCR.COM>, I write: >It's interesting to me how this thread is re-inventing the opaque >directory object proposed as part of the Secure Multics Project. In article <4468@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >In a sense, but not exactly. Essentially I want unix [sic] to be a >capability based system, at least in terms of the filesystem >interface. So when you get ahold [sic] 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. ... [ more description/justification deleted ] Humpf.... I guess that's what I get for posting while I was tired and not taking the time to express myself well. Your description is an \excellent/ one of the opaque directory objects -- I couldn't have described it any better. The only difference is that you want to have the permissions established a priori rather than when the object is evaluated. Opaque directory objects were motivated by the desire to be able to hide the layout of a file system from an external program -- in other words, so that you couldn't pass information from the secure side to the unsecure side by exploring the directory set up. You were allowed to create a handle on an object that you couldn't look inside. You could request operations on the object (add file name components and so forth), but until you tried to instantiate the object, you had no idea if it was valid or not. Another way of saying this is that the permissions of the object accumulated as it was manipulated, but were not visible externally until you tried to use it -- the equivalent here would be to open it or chdir to it. My point here is that the permissions required are an intrinsic part of the \use/ of an object, not of the evaluation of its name. You will have to track the permissions so you can do the right thing when the handle is instantiated, but, abstractly, it's not necessary to know what permissions will eventually needed. (Efficiency it a different issue; it may indeed be useful to provide hints to speed up the process.) Oh, and I don't think you'll find it in Organick; this particular proposal was much later. It may not have ever been formally published; I think I read it as part of a DARPA work proposal. Perhaps there's a collector of Multics papers that can say..... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (04/18/89)
In article <1265@ncr-sd.SanDiego.NCR.COM> Greg.Noel@SanDiego.NCR.COM (Greg Noel) writes: >My point here is that the permissions required are an intrinsic part >of the \use/ of an object, not of the evaluation of its name. It is, however, desirable to have permissions for the evaluation of the name too, for sometimes you don't want them to know even what it is they don't know anything about. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
bph@buengc.BU.EDU (Blair P. Houghton) (04/21/89)
In article <1277@ncr-sd.SanDiego.NCR.COM> Greg.Noel@SanDiego.NCR.COM (Greg Noel) writes: >In article <6839@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >>It is, however, desirable to have permissions for the evaluation of the >>name too, for sometimes you don't want them to know even what it is >>they don't know anything about. > >Seriously, your point is well taken; but the thing about the opaque object >was that it could just as easily represent a non-existant object -- the >operations on it "look like" they still work, so the user of the object >doesn't know what it is they don't know anything about.... These two statements taken together may just form the DoD-spec version of VMS, logicals and all. I'll go look-see and get back to you on that... --Blair "Almost got the microfilm into my vt340 now; just a few more yards..."