In article <9507272046.AA23637@cthulhu>, Mike Long <mike.long@analog.com> 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.
>> or
>> 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
   either:
   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.
   or
   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
     symlinks only).

However, this would clutter the symlink picture by a fair bit ....

					-jarle
-- 
"Filenames are only for people who can't remember where they put their
 files."
				-- Tarjei T. Jensen