On Thu, Dec 06, 2001 at 09:06:10AM -0600, Dave Dykstra <[EMAIL PROTECTED]> wrote: | On Fri, Dec 07, 2001 at 12:58:31AM +1100, Cameron Simpson wrote: | > Not so. The sunos4 boxen don't have lchown() | | You're right. However, the chown man page says it doesn't follow symlinks: | | If the final component of path is a symbolic link, the own- | ership and group of the symbolic link is changed, not the | ownership and group of the file or directory to which it | points.
Hmm. | > Another counter example - Apollo symlinks were special directory entries, | > not objects with inodes, and chowning them was meaningless. SInce the | > target permissions were always enough anyway (permissions on a symlinks | > can be trivially bypassed by opening the full path, and symlinks are | > not writable themself - only creatable), so inodeless implementations | > are both feasible and sensible. | | Does anybody run rsync on Apollo? Hell, they run it on Windoze :-( I know what I'd rather use. Still, that's not the point - the point is that it's dangerous. | > Please - if there's no lchown DO NOT chown symlinks. It is silently | > destructive. | I say let's don't bother to change it unless somebody reports a problem. Please don't take this path - ownerships on symlinks are a pretty meaningless concept and they day you run into a system like SysV but which doesn't have (or hides) its lchown rsync _will_ start damaging things nastily the day someone copies a tree with symlinks off into other places. It's like a timebomb. Imagine some simple auth system using the system password file, secure in the knowledge it's running unpriviledged and thus safe to symlink /etc/passwd into the config dir? Then updating their distro with rsync-as-root from some master server. Why _not_ take the conservation approach "unless somebody reports a problem" [sic]? -- Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/ ... It beeped and said "Countdown initiated." Is that bad?
