> On Fri, 13 Dec 1996, nw wrote:
>
> > Date: Fri, 13 Dec 1996 18:18:36 +0000 (GMT)
> > From: nw <nw@hydaspes.if.org>
> > Dan Merillat wrote:
> >
> > > On Fri, 13 Dec 1996, Steve VanDevender wrote:
> > > Theodore Y. Ts' <tytso@MIT.EDU> Writes:
> > I think that the various participants are each using the word "modify",
> > and possibly word "file" to mean slightly different things. You make some
> > interesting points but perhaps a bit more precision of speech would help
> > the discussion.
Some more terminology ...
> Um, I believe you know more about unix permissions then that.
>
> harik@chaos:~$ ls -alt ~/hidden
> total 12
> drwx------ 2 harik admin 1024 Dec 13 14:51 .
> -rwxrwxrwx 1 harik admin 1240 Dec 13 14:51 mycreditcards
> drwxr-xr-t 47 harik admin 9216 Dec 13 14:50 ..
>
> Would you say that the file is worldreadable? worldwritable? No, because
> the permissions on the file are the SUM of the permissons of the file and
> the directory...
Sorry, no. Under Unix, "file permissions" are defined to mean the stuff
located in the inode.
What you are talking about is access(2).
Please, let's not redefine common terms.
> Granted, nobody would be stupid enough to make their credit card numbers
> world writable, but the example holds. hard links can change the ability
> to access a file WITHOUT the owner's permission or knowledge.
Another one - while most people probably wouldn't notice, the link count
does tell about these things, and ls -l shows it.
> For a more applicable example:
> /usr/sbin/admin is a directory that only people in group admin can access.
> inside are user modification tools, suid root, executable by group user-adm.
> Therefore, the permission to modify a user is dependant on being in both
> group admin and user-adm. Why two levels? Because on any heirarchy there
> are going to be groups of administration that overlap.
>
> Makes sense right? Except having any directory on the
> same partition as /usr/sbin/admin writable by group admin destroys the
> entire scheme. And that's not something that many people realise.
This is not a sensible setup.
If admin is higher up in the security chain than user-adm, group
executability is useless; if it's the other way around, limiting the
directory to admin doesn't get you anything (and doesn't open any holes
either); and if they are unrelated (hard to imagine), then having the
subset of both priviledged to some tools doesn't make any sense that I can
see; furthermore, a vastly simpler solution would certainly be a new group
- combined-access security is hard to understand and hard to get right.
After all, this thread exists because we can't agree which way *is* right.
> I'm not talking about hiding data. I'm saying that the lifespan of
> a file is something that only the owner should be able to modify.
Certainly not.
Scenario:
~userA/incoming is rwxrwxrwx
userB puts a 3 GB file there
Should userA not be allowed to unlink that file?
> I like that quote... "platonic ideal entity" If you want to propose a
> different term for the whole thing, go ahead. So yes, I'm talking
> about the whole file entity, because a file is just that: the sum
> of the data blocks, the inode and the directory entery.
Except in a world of multiple links, this picture doesn't work.
Think of a library with multiple indices. The index entry is not a part of
the book.
MfG Kai