On Aug 1, 10:33am, der Mouse wrote:
} Subject: Re:  Symlink ownership
} > 	* chown() as far as I could tell never affected the symlink
} > 	  itself, although if, as you say, ownership were to be
} > 	  significant, we'd need lchown().
} 
} > 	* lchmod() would not be necessary, since modes on a symlink are
} > 	  never relevant.
} 
} By why aren't they?  It would make perfect sense, to me, for the r
} permission to control who can readlink() the link and x to control who
} can follow it during a normal path walk.  (No reasonable meaning for
} the 07222 bits comes to mind.)

Well, if you have x permission, then you can follow the link, find
out where it pointed, and do a pretty fair job of deducing it's contents
even without readlink() access.  This isn't foolproof (you might have
trouble distinguishing relative vs. absolute paths, various
non-canonical forms, a link that points to another link, etc.)

} What do _you_ propose in answer to the POSIX problem, then?  I've been
} able to see only a few solutions:
} 
} 1) Symlinks are full inode entities, with all the info showing through
}    when lstat() is done.
}  1A) Attributes can't be changed.
}  1B) Attributes can be changed with chown(), utimes(), etc.
}  1C) Attributes can be changed with lchown(), lutimes(), etc.
} 2) Symlinks are inodes or funny directory entries or maybe something
}    else, but they appear ownerless, timeless, etc.
} 

I much prefer (1) to (2).  IMHO (1B) flies in the face of too much
tradition (grossly violates POSIX).  I'd vote:
	1C, 1A, 2, 1B

			---  Truck