Messages in this thread |  | | Subject | Re: Proposal: restrict link(2) | Date | Fri, 13 Dec 96 13:15:21 PST | From | Craig Milo Rogers <> |
| |
<sarcasm> >> I understand quite clearly that making a link to a file does not affect >> either the data or the inode (aside from the link count.) However, link() >> has the rather unexpected side affect of allowing someone who is NOT the >> owner of a file to have the ability to prolong the lifespan of a file >> indefinitely. And that is a modification, and should be restricted to >> those with write access to the file, if not the owner. > >Horrible, horrible!!! A person with read access to a file can copy the >file, thus having the rather unexpected side effect of allowing someone >who is not the owner of a file to have the ability to prolong the >lifespan of the contents of the file indefinitely.
Worse still! The new copy of the file can have different access protections; it could even be made world-readable! </sarcasm>
As a more constructive comment, I note that what we're discussing is similar in spirit to the special meaning of the sticky bit for directories in "some filesystems" (hmm, I haven't found any Linux man pages that state which filesystems do what in this regard). Presumably, what you'd like is:
1) A new attribute for files that means "only the owner of this file (or the superuser) is allowed to link to it" (for completeness, it would be nice to have a group-level equivalent, too).
2) A new attribute for directories, mounted file systems, and/or user processes that, when set, will automatically set the file-level attribute described above in any new files.
This approach requires one ot two new ext2fs extended attributes and changes to various programs. Alternatively, for Unix timesharing services, you might be satisfied with a mount option that changes the behavior of link(2) for all files on the mounted filesystem; this requires changes to fewer programs.
Craig Milo Rogers
|  |