Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.bugs Subject: Re: bug with ufs file creation Date: 13 Sep 1993 14:28:30 GMT Organization: University of Maryland Lines: 112 Message-ID: <27202e$7u@umd5.umd.edu> References: <328@rook.ukc.ac.uk> <CD0AnI.1rM@taronga.com> <CD44wx.LHs@rex.uokhsc.edu> NNTP-Posting-Host: roissy.umd.edu If you're interested in proposed ACL semantics, skip to the end of this article. (I had to respond to some specific points too.) In article <CD44wx.LHs@rex.uokhsc.edu> benjamin-goldsteen@uokhsc.edu writes: > > I agree! I vote for real ACL's -- not even the hybrid crap. AOS >(an old proprietary OS for the DG Eclipse line -- which the U of >Oklahoma HSC is still running [for WordPefect no less]) has real ACL's. >Now, you might say, well, "bringing up an old proprietary OS is not >exactly a way to strengthen your point", but I disagree. The Since you bring up old proprietary OS's... Here is what TOPS-10 did: If the regular permissions failed, the system scanned the ACL. Otherwise, it just used the regular permissions. I thought this worked quite well. It also makes a nice performance gain when you don't have to scan an ACL for most files. > I also think that running both ACL's and permissions is too >confusing. It never bothered me, except on systems that use AFS (Andrew File System) where you can look at a file that says -rw-r--r-- 1 mark sw 520 Mar 5 1993 .cshrc and the group and world **DO**NOT** have access to READ the file. I suggest that if you do it right, you can avoid this kind of confusion. > Now, there is probably going to be too much overhead with ACL's on >say a USENET spool disk so lets make it a file option (just like layout >policy's, block size options, and space-time trade-offs, we have >security choices). I think this would be absolutely necessary, but then you have to keep the traditional permission scheme around. > I think we would need to be able to set these on a user-by-user and >group-by-group basis: > >Directories: create files, delete files, modify files, view >Files: read, write, execute, delete (? may be overkill -- we also end > up with the same permissions in two places), append (example: > appending to a log file) Try not to break existing semantics here. For example, ln /etc/passwd . rm -f passwd If you have "delete" > We would also need better group support. Perhaps each user should >be able to create groups (which would essentially become short hand for >the list of users). Lots of ACL based systems have a way to do this. > Perhaps some way to force the permissions for files >stored in special directories, too (i.e.How would we scaled up SGID >directories?). You inherit the ACL from the directory the file is created in. Linking a file does not change the ACL. > All of this would probably explode the size of the inodes (as well >as pushing "ls" into multiple-lines/file [bad]). How about then, just >adding an extra field: gid2. Gid2 would be a second gid field so that >you could say maintain a datafile with yourself as the owner, a bunch >of trusted colleagues with read/write access, a few other people with >read access, and no-access to other access to the world. Not that I >actually approve of this idea... Actually, many ACL systems work like this: An ACL is just another file. The "inode" [see note below] contains a pointer to the inode of the ACL. When you make another file with the same ACL, you re-use the ACL. Of course, the ACL has a reference counter. The "fsck-equivalent" knows to purge unreferenced ACLs and knows how to combine duplicates. Editing an ACL really makes a new one that is a little different. Note: I think ACLs don't fit as nicely into unix-like systems because of the file system semantics. For example, on VMS (which has ACLs and rwx-like protections) a file can only exist in one directory at a time. Thus the problem of linked files never comes up. On Apollo DOMAIN, directories don't have any influence on protections-- there is a system call that on unix would be like open() taking a device and an inode number. ALL of the protection rests in the ACL. Unix users (IMHO) *like* the idea that you need permission on a directory to get to the files in that directory. Therefore, I suggest that ACLs work like this: If the file protections fail on an attempted access, pass the request on to the ACL handler. The ACL handler looks up an ACL for that file and looks for an entry that would grant or deny access, then sends the result back to the kernel function that asked for it. An ACL can grant/deny read, write, and execute, just like normal files. You can't deny delete-access because Unix doesn't *have* delete access. You can't grant append-access, because nobody opens files for appending. This might be painful over NFS, since each read/write request would have to be serviced by the ACL handler... What do you think? Mark S.