Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!rex!ben
From: ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
Subject: Re: bug with ufs file creation
Message-ID: <CDELEB.8vo@rex.uokhsc.edu>
Date: Wed, 15 Sep 1993 16:20:34 GMT
Reply-To: benjamin-goldsteen@uokhsc.edu
References: <328@rook.ukc.ac.uk> <CD0AnI.1rM@taronga.com> <CD44wx.LHs@rex.uokhsc.edu> <27202e$7u@umd5.umd.edu>
Organization: Health Sciences Center, University of Oklahoma
Lines: 144
mark@roissy.umd.edu (Mark Sienkiewicz) writes:
>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.
I like that idea, too -- I guess I forgot to put "pass-though" as one
of the possible accesses.
>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.
Perhaps "delete" was wrong; I should have said "unlink"? Anyway,
perhaps we ought to move forward on this. Nobody uses these features right
now, but perhaps that could be coerced to?
>This might be painful over NFS, since each read/write request would have to
>be serviced by the ACL handler...
>What do you think?
My problem with having both -rwx and ACL's for the same file is that
like things can be set in two places. In you system, the it is not too bad
-- the only confusion would be if you did "chmod go= myfile", but forgot to
change the ACL's. The reason I bring this up is that things which are easy
to forget are forgoten -- one of the things I was taught (from where?) to
look out for in terms of security breakins was ".xyz" (especially in
/usr/bin or somewhere with a lot of files) because most(?) people do not
have "-a" turned on by default with their "LiSt files command" (ls, dir,
whatever you use most often). This is why I proposed that we rip out the
permision mode bits and pop in ACL's of some sort right there in the inode
(on a filesystem-by-filesystem basis). You look in once place and either it
is set or not.
However, now that I think about it -- this is old school. Perhaps we
ought to think of something better. It would be nice if it is simple,
elegant, but still powerful like UNIX is supposed to be. I am not
dismissing the pointer to the ACL in the inode, though. I will have to
think about that one.
Thank you for your consideration.
P.S.Let's keep in the UCB tradition -- break everything ;-)
--
Benjamin Z. Goldsteen