Messages in this thread |  | | Date | Fri, 13 Dec 1996 15:12:03 -0500 (EST) | From | Dan Merillat <> | Subject | Re: Proposal: restrict link(2) |
| |
On Fri, 13 Dec 1996, nw wrote:
> Date: Fri, 13 Dec 1996 18:18:36 +0000 (GMT) > From: nw <nw@hydaspes.if.org> > To: linux-kernel@vger.rutgers.edu > Subject: Re: Proposal: restrict link(2) > > > Dan Merillat wrote: > > > On Fri, 13 Dec 1996, Steve VanDevender wrote: > > > > > "And therefore modify?" I get the impression that some of the people > > > who are arguing about this don't at all understand the semantics of > > > link(). > > > > > > If you link /etc/shadow to /tmp/shadow, you have done none of the > > > following: > > > > > > * changed the permissions of /tmp/shadow > > > * changed the owner or group owner of /tmp/shadow > > > > > > Not only have you not changed those, you cannot change those. You have > > > created another reference to the inode, and that's all. > > > > > > Theodore Y. Ts' <tytso@MIT.EDU> Writes: > > > > > Incorrect. Being able to link to a file does not mean you can change > > > it. > > > 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.
file: an abstraction that is the union of all the information about a piece of data. This includes the data itself, a name, a location, and permissions.
modify: to change _ANY_ of the above.
> > If i may respond to some of your specific statements... > > > Sheesh. I said link() modifies a file. And it _DOES_ It changes the file > > location, > > What do you mean by "file location"? It adds a new pointer to the inode in > the directory tree; it does not move the previous pointer, nor any of the data > blocks.
Yes... that means it is accessable from a new location... and it does not notify the original owner that this is the case. Normally, not a problem. However, if I delete a file I expect it to be deleted... I don't expect some random user to have linked it to his directory. This is espically common in university environments with low disk quotas.
> > > which _MAY_ change permissions of that file! (think of a > > group-only > > directory and someone in that group makes a link outside of it) > > The new pointer may not be accessible to the same set of user/group ids as the > old one, but i don't see how this changes the permissions of the file.
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...
So a hard link outside of this directory WOULD change the permissions... not on the inode, but it changes the ability to access the file.
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.
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.
So, simply put, link() bypasses ALL group restrictions except the one on the file itself... and therefore it is something that administrators should be able to restrict.
> > It changes the lifespan of the file. > > It takes control of the file away from the owner, who can no longer delete > > the file. > > link() in a directory you own, mode 700. Now the owner _CANNOT_ > > touch the file after they remove it! > > Interesting point. However if the mere existence of the data blocks, even > if they are unreadable to anyone else, disturbs you that much, you should > encrypt the data, and/or don't keep it on a multi-user system.
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. Obviously you want to write /dev/zero or /dev/random all over your data if you want to make sure it's deleted... and burn all tape backups, etc. But I'm talking about transitory files that get their lifespan prolonged by another user. Besides, if you want to delete a file, do you _REALLY_ want to have to stat filename ls -i filename find /<mountpoint> -inum <number> -exec rm {}
> > > So yes, link() DOES modify a file > > and nobody can claim it does not! > > I think you mean "should", not "can". But, as noted above, i think you are > using the word "file" to mean something different than some others in this > discussion. You seem to think of the file as some sort of platonic ideal
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.
> entity, while others are using the word to mean just the data blocks of the > file, while yet others seem to mean the data blocks + inode.
True. But then they should be talking about datablocks or the inode or both.
--Dan
|  |