>>> Symlinks have had permissions approximately forever [...]
>> Actually, IIRC, symlinks permissions defaulted to 777, did they not?
>
>777 modified by the creating process's umask, in my experience.

actually, just plain old 777.  for example:

	% uname -a
	SunOS echonyc 5.6 Generic_105182-12 i86pc i386 i86pc
	% ln -s foo bar
	% ls -l bar
	lrwxrwxrwx   1 andrew   net            3 Oct 29 15:58 bar -> foo

this is the way it has always been, afaicr, and i expect that's the
way it still is on anything not derived from 4.4bsd.

it wasn't until 4.4bsd that this started changing, first with the
symlinks being rolled directly into the directory datablock (and not
having inodes or permissions at all).

then after they got pulled back out, they got their own permissions
and finally ways for us to tweak them (lchown, lchmod, etc), though
the owner and mode of a symlink still have (almost) no semantics of
their own.  certainly nothing standardized.

imho, by symlinks having no permissions semantics, and a useless owner
and group field, they are more like what they're meant to be:
cross-device links.  if you have a hard link to something and a
symbolic link to something, the following operations *ought* to
operate in the same manner:

	open(2)
	chown(2)
	chmod(2)
	utimes(2)
	stat(2)
	statfs(2)
	chflags(2)
	etc

and i think they do.  link(2) is the only questionable one.  do you
really want a hardlink to a symbolic link, or do you want a hard link
to the actual file?

the "falling down" is in that of the section 1 programs that try to be
more intelligent about what they're doing...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."