der Mouse responding to Tobias Weingartner:

> > 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?

And I shiver as well...

Why? Because the point of the POSIX standard is portable applications,
and I have a hard time seeing how that goal is advanced by expansion of
the symlink semantics beyond the point of industry consensus. If the
industry segments represented in the POSIX working groups could only get
consensus with the current minimal specification of symlink functionality,
what purpose is served by insisting that NetBSD must extend the semantics
in a way that would encourage non-portable application development?

With respect to the mode extensions, symlinks are only a short-cut to
traversal of the "real" filesystem. As such all access is already
mediated by the modes of each path component, and adding mode
interpretation to symlink evaluation contributes complexity and removes
performance without a corresponding benefit. I categorically reject any
change that would let symlink permissions override the access
permissions of "hard" filesystem entities. That is clearly outside the
bounds of existing art in this area.

I do not claim the present design is perfect, only that it is sufficient.

> > 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".

I am not certain that such claims are made on the basis of direct
inspection of the relevant draft. I will agree that posting the actual
text is probably not worthwile, because it is a series of edit directives
for changes to be made to the base standard. I will however summarize
the specification, based on the last draft balloted (P1003.1a/D12).

The definition of pathname resolution is modified to follow symlinks by
default unless otherwise noted for an individual function. Path resolution
in the presence of symlinks is specified in terms of string concatenation.
The traditional functions for dealing with symlinks (symlink, readlink,
and lstat) are specified. In struct stat, POSIX only specifies that
"st_size" and "st_mode" have meaningful information for symlinks, and that
the st_mode value is only meaningful as the argument to the S_ISLNK() macro.
There are also changes to handle a few corner cases in functions like open(),
These cases are largely things like opening a path naming a symlink
(return with error if O_CREAT|O_EXCL).

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

Yup, that is my recollection too, though I would have to find a copy
of the original source tapes to verify. I have always considered symlink
ownership and permissions a side-effect of their implementation, and not
otherwise used by the system. Yes I could change their values, but that
never affected their application or interpretation in path resolution.

> > 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.

As I commented above, the effective pathname acheived by evaluating the
symlink already has the owner/permissions protection. Adding it to symlinks
would introduce a source of conflicts in access protection.

> > 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?

A plausible explanation is that during path resolution, if you have already
gone to disk for the directory, why go to disk again for the content of
an symbolic link. Symbolic links as directory entries can be considered
a disk access optimization. Like all optimizations, the assumptions can
be invalidated in a number of ways, but those usually get swept under
the rug when justifying such a change..

> (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.

The core functionality of symlinks is simply a string that gets pathname
resolved before finishing the remainder of the original path. Given that,
all else is embellishment, and extraneous to the problem at hand. Lameness,
or the lack thereof, has nothing to do with it, except as a perjorative
intended to factionalize the discussion and deflect away from the goal
of supporting interfaces for portable applications.

> 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.

If you like. The real story is that the POSIX draft does what has not been
done previously, and clearly specifies how a symlink gets interpreted by all
interfaces that take pathnames. It does this by establishing a blanket rule,
and by declaring the cases where exceptions occur. If additional exceptions
are needed, by all means suggest them. I will be more than happy to forward
them to the POSIX working group. Convince me, and I will actively lobby for
useful changes to the draft language. We are dealing with a document that is
still in ballot, so clarifications are not impossible (radical change may
not be well received though).

/sjd