Subject: Re: lib/30664: realpath and magic symlinks
To: None <email@example.com, firstname.lastname@example.org,>
From: Christos Zoulas <email@example.com>
Date: 07/08/2005 13:38:26
On Jul 8, 5:24pm, firstname.lastname@example.org (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.