Messages in this thread |  | | Date | Fri, 13 Dec 1996 10:10:56 -0800 | From | Steve VanDevender <> | Subject | Re: Proposal: restrict link(2) |
| |
Dan Merillat writes: > Sheesh. I said link() modifies a file. And it _DOES_ It changes the file > location, which _MAY_ change permissions of that file! (think of a group-only > directory and someone in that group makes a link outside of it) > > 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! So yes, link() DOES modify a file > and nobody can claim it does not!
link() modifies the inode (by changing the link count and possibly the time stamps on the file) and it modifies a directory (by writing a new entry into that directory). It does not modify the file data. The linked file in a new directory may have different effective access permissions because of the permissions on the directories above it, but it still does not change the permissions of the file that was linked to. Neither does it modify the file data.
There seems to be a lack of deep understanding about how link() works and the relationships between directories, inodes, and file data, because people either keep using inappropriate terminology or showing substantial ignorance about what actually happens when links are created and removed.
And, to bring this back on topic, the original proposal was to only allow hard links to files that you have read access to. Unfortunately that proposal won't affect any of the scenarios you mention in reference to files that are readable by you.
|  |