Subject: Re: lib/30664: realpath and magic symlinks
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Chuck Silvers <chuq@chuq.com>
List: netbsd-bugs
Date: 07/08/2005 17:24:01
The following reply was made to PR lib/30664; it has been noted by GNATS.
From: Chuck Silvers <chuq@chuq.com>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org,
NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
Subject: Re: lib/30664: realpath and magic symlinks
Date: Fri, 8 Jul 2005 10:23:30 -0700
On Fri, Jul 08, 2005 at 09:02:19AM -0700, Jason Thorpe wrote:
>
> On Jul 4, 2005, at 4:26 PM, yamt@mwd.biglobe.ne.jp wrote:
>
> >>Description:
> >>
> > realpath(3) (or, more generally, userland code which resolves
> > symlinks by itsself using readlink(2)) doesn't handle
> > magic symlinks and can cause problems.
> > it's subtle because it isn't obvious which of userland or kernel
> > resolves a symlink for a given application.
>
> Perhaps readlink(2) should translate the magic symlink? But that
> would break ls(1). Perhaps we could add a readlink2(2) that takes a
> flags argument, allowing us to specify "raw" or "translated".
> readlink(2) would default to "translated", and ls(1) would be changed
> to use "raw".
I think that the real problem is having the path interpretation be different
for symlinks vs. other path lookups done in the kernel. it would make
a lot more sense to have the tranlation done for all pathname lookups
or none, and not this awkward halfway thing that "magic symlinks" provides.
then readlink() would be fine as it is.
-Chuck