Re: How does chown(2) works with symlinks?

Zefram (A.Main@dcs.warwick.ac.uk)
Tue, 9 Jul 1996 17:12:06 +0100 (BST)

>> fd = open(...);
>> fchown(fd,..);
>>
>> which should always work the way you expect.
>
>So long as you can open the file. Its possible you want to chown a file
>you own
>but can't open, and if chmod is consistent with chown (which I certainly
>hope
>is the case), you won't be able to chmod it before trying to open it.

Hello? Are we talking about the same operating system here? Who do
you think is allowed to change ownership of an inode? -- don't all
shout at once.

Admittedly POSIX.6 will make a difference to this, but it's hardly
insurmountable.

>It might be reasonable behaviour if there were ever a need to change the
>owner
>of a symlink. However, seeing as a symlink is a mere loophole in the
>namespace
>and has no function in itself, the owner, like its mode, is completely
>irrelevent.

symlink("/", "/tmp/symlink"). Now who can unlink("/tmp/symlink")?

>It seems to me that not following symlinks will be more surprising than
>following
>them, and therefore more likely to open holes.

It seems the reverse to me. Consider, for example, "chown -R
luser.users /home/luser", after it's been restored from tape. What
happens to the symlink to /etc/passwd that the user happens to have?
For what purposes do you call chown(2) anyway?

Please try to format text to lines of between about 50 and 70 columns
each.

-zefram