Re: chown and symbolic links

[Pavel Roskin <proski gnu org>]

Hi!

> : ~2 years ago I was able to chown a symbolic link. Now chown
> : modifies the library or any other file the symbolic links
> : points to.
>
> It seems I answed this question some time ago.
> I guess you are using Linux with 2.2+ kernel now and you used 2.0
> kernel ~2 years ago. There is NOTES section from chown (2) man page.

Thank you for figuring this out!

> : How do I get the old behavior ?
>
> There is a dirty hack below.

It's funny that some people call their dirty hacks "patches" and you are
calling your patch a "dirty hack".

This is basically what the "chown" command does in GNU fileutils, except
that it returns ENOSYS on symlinks if lchown is not available and chown is
not guaranteed to work as lchown.

It's already the second patch in the last month that tries to use the VFS
level to give the traditional libc functions the "smartness" of the
traditional UNIX utilities, such as "ln" that can link into a directory
and "chown" that works on symlinks.

I think we should decide whether using VFS for that is a good idea.  It's
a simple and working solution, but I want to make sure that it's the right
solution.  If VFS is used in other projects it's important to weigh
security consideration of making VFS a "smart libc".

Non-VFS builds could be considered until now a safer alternative for
systems with untrusted users.  Not fixing a security-related bug in
non-VFS builds could affect their adantage in this area.

Actually, at some point the support for non-VFS builds could be dropped.
Instead, the --without-vfs option would mean that only local.c should be
compiled (and that the extfs scripts should not be installed).  Does it
sound good?

-- 
Regards,
Pavel Roskin