Subject: Re: Symlink ownership
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Don Lewis <firstname.lastname@example.org>
Date: 08/03/1995 23:47:56
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