> I've been watching this thread a little, and every time I see another
> suggestion made, I have to cringe... ;-(

Why?  You don't really think they're all going to happen, surely?  (Of
the three suggestions I've made - symlink 0555 bits, symlink 0222 bits,
and symlink 06000 bits - even I have implemented only one (the first).)
Or do you think the current setup is so perfect that no suggestions
could be worthwhile?

> Could someone post the relevant parts of the relevant standards, so
> we can all work on real data, please?

I'm not entirely convinced this is worthwhile, since at least a couple
of people have been saying "let's ignore the standards on this issue,
since the standards are broken".

> My $0.02 worth are like so:  traditionally, symlinks were owned by
> UID & GID zero, and had perms 777.

What sort of system was _that_?!  Every pre-NetBSD system I've used has
had symlinks owned by their creators (uid) and creator or directory
owner (gid), same as if they were files created in the same directory.
Some of them (eg, 4.3) gave 0777&~umask for permission bits, others
gave them 0777; all of them ignored the permissions when accessing the
symlink.  Then along came these pseudo-unowned symlinks....

> It makes little sense to have any sort of protection based on [the
> owner and permission bits of a symlink]

I'm not sure why not; every other filesystem entity does something with
its ownership and permissions information.  My suggested interpretation
for the r and x bits seems fairly obvious; it's more or less what they
mean for directories.  The 06222 bits are a bit more far-fetched, but
still not entirely silly; indeed, set-id symlinks would be a very cheap
way to give capabilities that did not exist before.

> Also, kludging up the directory structure makes no sense to me.  Why
> do you want to hack up something beautifull?  Why masacre (sp?) a
> thing of simplicity, flexibility and function?

(Massacre, I think.)  I don't.  As far as I can tell, nobody does,
except non-UNIX systems that are trying to be POSIX and implemented
symlinks as funny directory entries on their own.  I'm not even sure
why 4.4 made symlinks unowned; from what's come across the lists here,
it seems to have been an attempt to avoid making lame systems feel
lame.  This is not worth even attempting IMO; considering the problems
it's causing, there's no question in my mind that it should be
reversed.

This leaves us with the problem of that POSIX draft which specifies
that a bunch of syscalls follow terminal symlinks, thus producing the
four-way dilemma I covered in another message.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu