Re: Proposal: restrict link(2)

Craig Milo Rogers (rogers@isi.edu)
Fri, 13 Dec 96 13:15:21 PST

<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