|
|
The following reply was made to PR lib/30664; it has been noted by GNATS.
From: Bill Studenmund <wrstuden@xxxxxxxxxx>
To: Jason Thorpe <thorpej@xxxxxxxxxxxxxx>
Cc: Chuck Silvers <chuq@xxxxxxxx>,
YAMAMOTO Takashi <yamt@xxxxxxxxxxxxxxxxx>, netbsd-bugs@xxxxxxxxxx,
gnats-bugs@xxxxxxxxxx,
NetBSD Kernel Technical Discussion List <tech-kern@xxxxxxxxxx>
Subject: Re: lib/30664: realpath and magic symlinks
Date: Fri, 8 Jul 2005 16:57:25 -0700
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 08, 2005 at 10:35:29AM -0700, Jason Thorpe wrote:
>=20
> On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:
>=20
> >I think that the real problem is having the path interpretation be =20
> >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" =20
> >provides.
> >
> >then readlink() would be fine as it is.
>=20
> So, the question is:
>=20
> Are these magic names interpreted by lookup() before handing them off =20
> to VFS_LOOKUP()? I would guess it would have to be, otherwise it =20
> would just be insane.
My thought is to keep the processing in namei(). Just change it so that=20
rather than looking at a path passed from a symlink (i.e. after lookup()=20
returns), we look at all paths before we call lookup().
I realize that this change would require magicname handling to be=20
system-wide rather than per-mountpoint. I think that's fine. After all,=20
the semantics are system-wide.
Take care,
Bill
--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCzxLlWz+3JHUci9cRAsiNAJ9CmD7rWBqibBXvblDz5R4APeWrBgCfS04s
UzUq8Ofu98km8cCbsONjo/M=
=TuO3
-----END PGP SIGNATURE-----
--LZvS9be/3tNcYl/X--
|
|