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: <CD44wx.LHs@rex.uokhsc.edu>
Date: Fri, 10 Sep 1993 00:48:33 GMT
Reply-To: benjamin-goldsteen@uokhsc.edu
References: <CCyLF6.n6@kithrup.com> <322@rook.ukc.ac.uk> <CCzu78.DJD@kithrup.com> <328@rook.ukc.ac.uk> <CD0AnI.1rM@taronga.com>
Organization: Health Sciences Center, University of Oklahoma
Lines: 77
peter@taronga.com (Peter da Silva) writes:
>In article <328@rook.ukc.ac.uk>, D.A.Clear <dac@ukc.ac.uk> wrote:
>> tikki% groups
>> staff wheel
>> tikki% ls -ldg .
>> drwxr-xr-x 2 dac games 512 Sep 7 20:02 .
>> tikki% touch foo
>> tikki% ls -lg foo
>> -rw-r--r-- 1 dac games 0 Sep 7 20:04 foo
>> tikki% chmod 2755 foo
>> chmod: foo: Operation not permitted
>That doesn't make sense. I can see using the directory group to choose
>which of *your* groups the file should be in, but what's the point of
>creating a file in a group you're not a member of by default?
>I suppose this is all part of the broken BSD chown semantics, inherited
>from the days of the Berkeley Fascist File System (not a dig... that's
>what it was called) with only group masters able to chown files owned by
>members of a group.
>I think that this whole area: groups, chown, quotas, and so on needs to
>be reconsidered. It's become a big mess.
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
permissions system should have been overhauled when BSD brought out the
multiple group thing. This is old stuff -- figured out a long time
ago. I believe there is a patch on Wuarchive for adding ACL's to
BSD4.2.
I also think that running both ACL's and permissions is too
confusing. Under AIX 3.2 the ACL's are hidden unless you use an extra
flag. Even then, you can not look at them unless you use another
command (which can only look at one file at a time!). Now, of course,
part of that is IBM fault, but part of it is inherent in mixing the two
(IMHO). We probably ought to look at some of the secure UNIX's and see
if there is any thing there (in terms of an interface) that can be
salvaged.
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 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)
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). Perhaps some way to force the permissions for files
stored in special directories, too (i.e.How would we scaled up SGID
directories?).
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...
Well, just throwing out ideas...they are worth what you paid for
them... I would play around with this myself if I had time. I do not
however -- I have to catch-up doing all the things I should have been
doing when I installed NetBSD-0.9 last weekend.
--
Benjamin Z. Goldsteen