Subject: Re: Symlink ownership
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Greg A. Woods <woods@kuma.web.net>
List: current-users
Date: 08/03/1995 10:57:07
[ On Tue, August 1, 1995 at 10:33:27 (-0400), der Mouse wrote: ]
> Subject: Re: Symlink ownership
>
> lstat() is not necessary if you just define stat() to not follow links,
> and then let people readlink() the link if they want the effect of the
> current stat(). (Of course, this flies in the face of lots of current
> tradition; I don't want to be taken as suggesting that this actually be
> done.)
I think it's way too late for this change in a UNIX/POSIX system....
> 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.)
I thik I like this....
> It's either that or have people able to create things in sticky
> directories and then be unable to remove them. Or else keep creator
> information for links, which would be a _major_ filesystem change.
But it might be a big win, and it might be worth it if it didn't change
the semantics of anything else...
> You're in the same situation with hardlinks - you have to do exhaustive
> search of everywhere the link could be. Hardlinks just make it a
> little easier because the other links are known to be on a specific
> filesystem.
You also know the inode number, and thus the real file data is always
available too....
> 1B) Attributes can be changed with chown(), utimes(), etc.
> 1C) Attributes can be changed with lchown(), lutimes(), etc.
I'd personally vote for 1C, even though it makes me queasy. I think it
would permit more ultimate control than 1B which would otherwise be my
choice. I don't like *any* of the other options! ;-)
1C follows the lead of lstat(), after all.
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>