Re: patch to realpath(3) to make it DTRT(IMO) with variant symlinks

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Thu, Feb 05, 2004 at 01:19:15AM -0800, Chris Pressey wrote:
> OK, something more substantial: I discovered that realpath(3) (and
> consequently realpath(1) too) do not act as one probably would expect
> when an element of the path is a variant symlink.
> 
> The attached patch is one way to correct realpath's behaviour.  It is
> quite probably not the best way, but it seems to work (it's been
> modestly tested.)  Other ways to address it might be:
> 
> - just don't make realpath resolve variant symlinks
> 
> I think that leaves the spirit (if not the letter) of realpath broken.
> Existing scripts expect realpath(1) to return a real genuine filename.
> 
> - make readlink(2) resolve variant symlinks instead

IMO this is the correct way.

> It's not uncommon for programs to 'abuse' the symlink target, never
> intending for it to point to a real file (e.g. malloc, cvsupd, the
> webserver 'fnord', ...) and while I'm not aware of any that rely on a
> ${}-like syntax in the symlink, it seems best to give them exactly what
> they're asking for: the contents of the symlink, verbatim, regardless
> of what it 'means'.

Those symlinks should be resolved by realpath(3), otherwise the
program is broken.

> - make varsymreplace a syscall
> 
> Too rich for my blood :)  Could be better for consistency though (e.g.
> my patch doesn't check vfs.varsym_enable; it probably should.)

I don't like that one too. If Matt doesn't cry out loud, I'll change
the kernel source to allow them to share the implementation.

Joerg

> -Chris