The following reply was made to PR lib/30664; it has been noted by GNATS.
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: tech-kern@netbsd.org
Subject: Re: lib/30664: realpath and magic symlinks
Date: Fri, 8 Jul 2005 13:38:26 -0400
On Jul 8, 5:24pm, chuq@chuq.com (Chuck Silvers) wrote:
-- Subject: Re: lib/30664: realpath and magic symlinks
| > 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.
I totally agree with that. For now the best course of action is:
1. Leave magiclinks in, default off; mark it experimental and don't pull it
up to 3.1
2. Create sysctl to turn on/off readlink() return behavior. This sysctl
"proc.pid.magiclinks" (or something) defaults to 0, and is inherited
across fork and exec. If proc.pid.magiclinks==0, readlink returns the
translated path; if ==1 then it returns the raw path.
3. In the long term, move the whole mess to namei(), deprecate magiclinks.
and rename the magiclinks mount option magicnames.
christos