tim (11/29/82)
Since everyone is suggesting impossible changes
in the UN*X protection system, I would like to put in
my two cents worth for separating writing from deleting.
VMS protection is a simple 4x4 arrangement: read, write,
execute, and delete for each of system, owner, group, world.
("System" includes such things as the mail utility.) I have
serious reservations about UN*X considering writing files
equivalent to deleting them. Sure, if you grab the thing with
a text editor, you can empty it if you have write protection,
regardless of delete, but in practice the two operations
tend to be rather different. In particular, it is nice
to be able to write a directory without being able to
delete it. Since unlink is a separate function from
create and write, this doesn't seem conceptually impossible
to implement.
Tim Maroney
unc!timminow (11/30/82)
Tim Maroney's suggestion -- that Unix implement VMS Read/Write/Execute/Delete
protections -- forgot to mention that VMS, unlike Unix, implements file
versions. Thus, programs generally blindly create output files. If
something blows up, you can delete the most recent instance of a file.
I frequently clean out trash from my accounts and, in order to avoid
cleaning out something that may look like a temp file but isn't, I
set its protection ("Owner may not delete"), then do the deletion,
ignoring the warning message. The owner may always reset the protection,
by the way.
Version numbers are a mixed blessing, however, as forgetful users can
leave hugh numbers of random junk around.
No free lunch.
Martin Minow
decvax!minowswatt (11/30/82)
There is at least one other problem with VMS-style file permissions, and that is that each FILE carries its own DELETE permission modes with it, rather than having the parent directory's permissions determining delete permissions for all files in that directory. I always seemed to end up in the situation where somebody else had put a file in my area which I couldn't delete for love nor money. This was back a ways though, perhaps they've fixed it. - Alan S. Watt
mark (11/30/82)
Oh, boy! Impossible changes to UNIX! What fun! Well, somebody out there may be designing a new UNIX, so what the hey? My pet peeve is that files need more than one set of group bits (and more than one gid field). At least two, maybe more. I've seen cases where you want one group to be able to write in a directory (say group sys and dir /usr/src/cmd) and another group (say users you trust) to be able to read it but not write it, and then there is the rest of the world that isn't allowed to read it either (because you signed a UNIX license that made you promise not to let the source code out, and uucp lets anybody steal it).
4341shn (12/01/82)
On a DEC-10 I used in college a few years ago, it had a system where if a file access bombed out due to lack of permission by the permission bits, a special file was checked for special cases such as a particular user, group, etc. This would allow the majority of files to be handled efficiently (assuming the current permission field is efficient) and allow exceptions. Also, it could easily be added on top of UN*X as it exists now with modifying anything that depends on inode formats.
cak@Purdue@sri-unix (12/09/82)
From: Christopher A Kent <cak@Purdue> Date: 4 Dec 1982 16:33:48-EST With the new group stuff that's coming with 4.2 (you are in all the groups you can be, all at once), I could live with one set of group bits. BUT, I'd like to see a fourth set of bits for 'the outside world'; we don't have anonymous FTP because of our Unix license and the fact that we want our users to be able to read the sources. Of course, a hack may be to create a pair of groups "internal" and "external", and make all local users members of "internal", and make everything in the /usr/src directory be mode 640, group owned "internal". Then uucp and FTP types would come in in group "external". I think this should work, but I won't know till I see the new code. I like delete permission just the way it is, thanks . Cheers, chris
gwyn@Brl@sri-unix (12/09/82)
From: Doug Gwyn <gwyn@Brl> Date: 5 Dec 82 2:56:17-EST (Sun) I haven't been able to think of a "group" scheme that is satisfactory in all respects. What about the idea of Access Control Lists, with the current scheme used in the default case of no associated ACL?
Michael.Young@CMU-CS-A@sri-unix (12/09/82)
From: Michael Wayne Young <Michael.Young@CMU-CS-A>
Date: 4 December 1982 1943-EST (Saturday)
Putting more than one set of group bits in is nice, but
how many groups? This suffers from the same sort of loss
of generality as 4.2BSD's allowing you to be in N groups
(for some fixed N). [Allowing any number of groups (with
a data structure similar to clist {like a "chunked array"})
would be nice: still you're limited to the number of
groups you can login/newgrp to anyway (because only those
things would give you new groups in your list anyhow).]
I think perhaps a better solution would be the creation
of a "file daemon" at this point. Something like what
Tops-10 has. I don't exactly like the Tops-10 approach,
but the idea of a file daemon (which could also support
neat things like password-protected files, among other
goodies) is nice. I've thought long and hard on it, but
haven't been able to come up with a reasonable implementation
of it for a Unix system though. Anyone else
have any good ideas?
The new 4.2BSD IPC ought to make a file daemon a little
easier to deal with too. Taking hairy protection computations
out of the kernel (for special cases only; not simple
accesses) may be well worth its while.
MichaelMichael.Young.CMU-CS-A@SRI-UNIX@sri-unix (12/13/82)
From: Michael Wayne Young <Michael.Young.CMU-CS-A@SRI-UNIX> Date: 9 December 1982 2001-EST (Thursday) Oh, I also wanted to point out that I think the bits we alreay have are nice. Even for directories... it's quite consistent. [Read and write have natural counterparts for directories, and execute is the remaining ability (search).] That's why I'd propose adding neat features with other mechanisms. [Like a file daemon or with special uids, the former being preferable, but harder to do.] Michael