Subject: Re: Symlink ownership
To: None <firstname.lastname@example.org>
From: Jarle Fredrik Greipsland <email@example.com>
Date: 07/28/1995 16:37:15
In article <9507272046.AA23637@cthulhu>, Mike Long <firstname.lastname@example.org> writes:
>> The least requirement one can pose on symlinks is that if you were able
>> to make a symlink in a directory, you should also be able to remove it
>> (just like it works with normal files and everything else). This would
>> require that
>> 1. everybody (who can write in the directory) can remove the symlink. This
>> is however undoing the effect the sticky bit is supposed to have.
>> 2. the symlink has an owner.
> How about:
> 3. Don't let a user create symlinks in a sticky directory he/she
> doesn't own.
> This solution satisfies the 'if you can create it, you can destroy it'
> requirement. AFAIK it should be easy to check for this condition and
> return EPERM, but I haven't actually looked at the code.
Even more suggestions:
4. Keep around two types of symlinks: The good, old file system
objects and the new, dum^H^H^Hsemantically challenged ones. Then
a) On a per file system basis choose which type to use. Thus, if
you've got a separate /tmp partition (mfs or ffs) you can get the
old sematics. In /usr, /home etc. you can choose the new one.
b) On a per directory basis, if the directory has the sticky bit
set, use the old symlink type. This ensures that the creator can
still remove the link. If the sticky bit isn't set use the new
type. One catch here is that if the directory is changed from
non-sticky to sticky the creator can't remove the symlink.
However, this is as a result of an explicit chmod-action from the
owner of the directory, and could be viewed as an adoption of all
symlinks in a directory (equivalent to doing chmod og-w, but for
However, this would clutter the symlink picture by a fair bit ....
"Filenames are only for people who can't remember where they put their
-- Tarjei T. Jensen