> I thought that one of the big decisions at Berkeley when making
> symbolic links was that they wouldn't have their own permissions, and
> that only the permissions on the referenced node would matter. ??

Back when symlinks first went in, they had permissions like any other
inode but their permissions didn't matter.

Then more recently NetBSD tried to make symlinks into more nearly
completely mode-free objects, apparently in preparation for
implementing them as something other than inodes, eg funny directory
entries.  This had so many problems it got backed out; see the list
archives for the full story.

I wrote some code to actually do something with symlink mode bits;
something very much like it (I think it may actually be basically my
code - been so long I forget) is now in the tree, accessible by
mounting your filesystems with the symperm option.  (The mount(8)
manpage doesn't say what permission bits do what; IIRC the read bits
control readlink() and the execute bits control following during path
walks.)

I've toyed with meanings for the 07222 bits, things like a setuid
(setgid) symlink doing the rest of the path walk (but not the operation
at the end) as the UID (GID) that owns the link, allowing set-id links
to punch through directory permissions in a controlled way, or having
the write bit allow symlink() to atomically replace a link...but
haven't actually implemented them.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B