NetBSD Problem Report #30664

From yamt@mwd.biglobe.ne.jp  Mon Jul  4 23:25:37 2005
Return-Path: <yamt@mwd.biglobe.ne.jp>
Received: from yamt.dyndns.org (FLA1Abp233.kng.mesh.ad.jp [220.144.226.233])
	by narn.netbsd.org (Postfix) with ESMTP id DE94E63B104
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  4 Jul 2005 23:25:36 +0000 (UTC)
Message-Id: <1120519531.703728.1628.nullmailer@yamt.dyndns.org>
Date: Tue, 05 Jul 2005 08:25:31 +0900
From: yamt@mwd.biglobe.ne.jp
Reply-To: yamt@mwd.biglobe.ne.jp
To: gnats-bugs@netbsd.org
Subject: realpath and magic symlinks
X-Send-Pr-Version: 3.95

>Number:         30664
>Category:       lib
>Synopsis:       realpath and magic symlinks
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 04 23:26:00 +0000 2005
>Last-Modified:  Fri Apr 06 15:40:01 +0000 2007
>Originator:     YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
>Release:        NetBSD 3.99.7
>Organization:

>Environment:


System: NetBSD kaeru 3.99.7 NetBSD 3.99.7 (build.kaeru.nodebug) #83: Mon Jul 4 07:32:21 JST 2005 takashi@kaeru:/home/takashi/work/kernel/build.kaeru.nodebug i386
Architecture: i386
Machine: i386
>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.
>How-To-Repeat:
	"install -lrs foo/bar/abc abc" where foo is a magic symlink.
>Fix:
	document?

>Audit-Trail:
From: Jason Thorpe <thorpej@shagadelic.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: 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 09:02:19 -0700

 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".

 Thoughts?


 -- thorpej

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: thorpej@shagadelic.org
Cc: netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org,
	tech-kern@netbsd.org
Subject: Re: lib/30664: realpath and magic symlinks
Date: Sat, 09 Jul 2005 01:14:34 +0900

 > 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".
 > 
 > Thoughts?

 i think it's a fine idea.

 YAMAMOTO Takashi

From: Hisashi T Fujinaka <htodd@twofifty.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 09:23:06 -0700 (PDT)

 On Fri, 8 Jul 2005, 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".

 Could this be my problem with toolchain/30682?

 -- 
 Hisashi T Fujinaka - htodd@twofifty.com
 BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

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

From: Jason Thorpe <thorpej@shagadelic.org>
To: Chuck Silvers <chuq@chuq.com>
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:35:29 -0700

 On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:

 > 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.

 So, the question is:

 Are these magic names interpreted by lookup() before handing them off  
 to VFS_LOOKUP()?  I would guess it would have to be, otherwise it  
 would just be insane.

 -- thorpej

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

From: Bill Studenmund <wrstuden@netbsd.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Chuck Silvers <chuq@chuq.com>,
	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 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--

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, tech-kern@netbsd.org
Subject: Re: lib/30664: realpath and magic symlinks
Date: Sat, 09 Jul 2005 23:10:15 +0900

 > 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.

 who is expected to toggle this sysctl?
 users, or applications?

 > 3. In the long term, move the whole mess to namei(), deprecate magiclinks.
 >    and rename the magiclinks mount option magicnames.

 i guess magicnames have its own weirdness...
 foreign filesystem/tarballs, remote files, etc.
 good luck. :-)

 YAMAMOTO Takashi

From: christos@zoulas.com (Christos Zoulas)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, tech-kern@netbsd.org
Subject: Re: lib/30664: realpath and magic symlinks
Date: Sat, 9 Jul 2005 10:35:07 -0400

 On Jul 9, 11:10pm, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
 -- Subject: Re: lib/30664: realpath and magic symlinks

 | > 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.
 | 
 | who is expected to toggle this sysctl?
 | users, or applications?

 Users. The point is not to make the whole tinh visible to applications.

 | > 3. In the long term, move the whole mess to namei(), deprecate magiclinks.
 | >    and rename the magiclinks mount option magicnames.
 | 
 | i guess magicnames have its own weirdness...
 | foreign filesystem/tarballs, remote files, etc.
 | good luck. :-)

 Why? The pathnames have @var's but they are otherwise valid.

 christos

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, tech-kern@netbsd.org
Subject: Re: lib/30664: realpath and magic symlinks
Date: Sun, 10 Jul 2005 00:16:02 +0900

 > | > 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.
 > | 
 > | who is expected to toggle this sysctl?
 > | users, or applications?
 > 
 > Users. The point is not to make the whole tinh visible to applications.

 i don't think it's reasonable to expect users to know
 how each applications resolve links (by readlink or not).
 it's the reason i filed this PR.

 besides, it likely depends on application, not user, which behaviour is
 expected.  eg. backup tools likely always want to see raw contents.

 > | > 3. In the long term, move the whole mess to namei(), deprecate magiclinks.
 > | >    and rename the magiclinks mount option magicnames.
 > | 
 > | i guess magicnames have its own weirdness...
 > | foreign filesystem/tarballs, remote files, etc.
 > | good luck. :-)
 > 
 > Why? The pathnames have @var's but they are otherwise valid.

 eg. if you have a file named "@var", you will see weird ENOENT on "ls -l".

 YAMAMOTO Takashi

From: Chuck Silvers <chuq@chuq.com>
To: Bill Studenmund <wrstuden@netbsd.org>
Cc: Jason Thorpe <thorpej@shagadelic.org>,
	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: Mon, 11 Jul 2005 10:30:32 -0700

 On Fri, Jul 08, 2005 at 04:57:25PM -0700, Bill Studenmund wrote:
 > On Fri, Jul 08, 2005 at 10:35:29AM -0700, Jason Thorpe wrote:
 > > 
 > > On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:
 > > 
 > > >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.
 > > 
 > > So, the question is:
 > > 
 > > Are these magic names interpreted by lookup() before handing them off  
 > > to VFS_LOOKUP()?  I would guess it would have to be, otherwise it  
 > > would just be insane.
 > 
 > My thought is to keep the processing in namei(). Just change it so that 
 > rather than looking at a path passed from a symlink (i.e. after lookup() 
 > returns), we look at all paths before we call lookup().

 I'll leave this level of detail to you folks that are more familiar with it.


 > I realize that this change would require magicname handling to be 
 > system-wide rather than per-mountpoint. I think that's fine. After all, 
 > the semantics are system-wide.

 I also think that having this be configured per-system instead of per-mount
 probably makes more sense.  otherwise you get into the confusing situation
 of having a symlink containing one of these magic names that lives in one fs
 but that points through another (or maybe several others), with the different
 fs's having different settings for magic names being enabled.  well...
 with NFS there's the same issue with different nodes having different settings,
 so I guess it's really unavoidable.  per-node seems like it would probably
 be less bad, though.

 -Chuck

From: Jason Thorpe <thorpej@shagadelic.org>
To: Chuck Silvers <chuq@chuq.com>
Cc: Bill Studenmund <wrstuden@netbsd.org>,
	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: Mon, 11 Jul 2005 12:28:50 -0700

 On Jul 11, 2005, at 10:30 AM, Chuck Silvers wrote:

 > I also think that having this be configured per-system instead of  
 > per-mount
 > probably makes more sense.  otherwise you get into the confusing  
 > situation
 > of having a symlink containing one of these magic names that lives  
 > in one fs
 > but that points through another (or maybe several others), with the  
 > different
 > fs's having different settings for magic names being enabled.  well...
 > with NFS there's the same issue with different nodes having  
 > different settings,
 > so I guess it's really unavoidable.  per-node seems like it would  
 > probably
 > be less bad, though.

 If we have consensus that we should just do this system-wide, then it  
 is a trivial change to make and I will go ahead and do it (and add a  
 sysctl knob for it).

 -- thorpej

From: Bill Studenmund <wrstuden@netbsd.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Chuck Silvers <chuq@chuq.com>,
	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: Thu, 21 Jul 2005 14:40:52 -0700

 --fUYQa+Pmc3FrFX/N
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 On Mon, Jul 11, 2005 at 12:28:50PM -0700, Jason Thorpe wrote:
 >=20
 > On Jul 11, 2005, at 10:30 AM, Chuck Silvers wrote:
 >=20
 > >fs's having different settings for magic names being enabled.  well...
 > >with NFS there's the same issue with different nodes having =20
 > >different settings,
 > >so I guess it's really unavoidable.  per-node seems like it would =20
 > >probably
 > >be less bad, though.

 per-node can also be the reason for using the symlinks (or names). :-) You=
 =20
 can easily link your ~/bin directory to one that is architecture-specific,=
 =20
 for instance. While they can be confusing, I think they also can be very=20
 useful.

 > If we have consensus that we should just do this system-wide, then it =20
 > is a trivial change to make and I will go ahead and do it (and add a =20
 > sysctl knob for it).

 Well, I've heard no objections to system-wide and a few "Ayes". So it=20
 sounds good. (I also am behind on source-changes, so you may already have=
 =20
 done this :-)

 Take care,

 Bill

 --fUYQa+Pmc3FrFX/N
 Content-Type: application/pgp-signature
 Content-Disposition: inline

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (NetBSD)

 iD8DBQFC4BZjWz+3JHUci9cRAt2aAJ4zrh6EOThJ+/fOT/MJC2xv2T6uogCdFYJL
 rxp+l3uljIYHbNoTohiFyKA=
 =SINu
 -----END PGP SIGNATURE-----

 --fUYQa+Pmc3FrFX/N--

From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: netbsd-bugs@NetBSD.org, gnats-bugs@NetBSD.org,
	tech-kern@NetBSD.org
Cc: 
Subject: Re: lib/30664: realpath and magic symlinks
Date: Thu, 21 Jul 2005 21:31:41 -0400 (EDT)

 > per-node can also be the reason for using [magic symlinks/names].
 > While they can be confusing, I think they also can be very useful.

 I would challenge you to find _any_ facility that can reasonably called
 "very useful" that cannot also be confusing if misused.

 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML	       mouse@rodents.montreal.qc.ca
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: Chuck Silvers <chuq@chuq.com>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Bill Studenmund <wrstuden@netbsd.org>,
	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: Mon, 25 Jul 2005 10:06:18 -0700

 On Mon, Jul 11, 2005 at 12:28:50PM -0700, Jason Thorpe wrote:
 > 
 > On Jul 11, 2005, at 10:30 AM, Chuck Silvers wrote:
 > 
 > >I also think that having this be configured per-system instead of  
 > >per-mount
 > >probably makes more sense.  otherwise you get into the confusing  
 > >situation
 > >of having a symlink containing one of these magic names that lives  
 > >in one fs
 > >but that points through another (or maybe several others), with the  
 > >different
 > >fs's having different settings for magic names being enabled.  well...
 > >with NFS there's the same issue with different nodes having  
 > >different settings,
 > >so I guess it's really unavoidable.  per-node seems like it would  
 > >probably
 > >be less bad, though.
 > 
 > If we have consensus that we should just do this system-wide, then it  
 > is a trivial change to make and I will go ahead and do it (and add a  
 > sysctl knob for it).

 that would be fine with me.

 -Chuck

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: christos@zoulas.com
Cc: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, xtraeme@netbsd.org,
	juan@xtrarom.org, core@netbsd.org
Subject: Re: kern/30664
Date: Fri,  6 Apr 2007 11:44:15 +0900 (JST)

 [ moved from PR/35675 ]

 > | > I am looking for something like solaris' resolvepath(2) which can be
 > | > used to implement the rest of realpath(3) in userland.
 > | 
 > | it isn't necessary to solve these PRs, right?
 > 
 > I think that it is a lot easier to handle magiclinks in one place
 > (kernel since this is where we resolve them now) as opposed to
 > either introduce a new system call that resolves them, or copy the
 > code to userland.
 > 
 > christos

 whatever libc realpath implementation is, there is no way to force
 applications to use the kernel version.  so, as far as we keep the current
 semantics of magiclinks, we need to modify readlink(2) anyway.
 and, if we choose to adapt readlink(2), there is no need to modify realpath.

 i'm not saying having resolvepath(2) is a bad idea.  (actually, i'm not sure.)
 i'm merely saying it isn't necessary for these PRs.  don't you agree?

 YAMAMOTO Takashi

From: christos@zoulas.com (Christos Zoulas)
To: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Cc: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, xtraeme@netbsd.org,
	juan@xtrarom.org, core@netbsd.org
Subject: Re: kern/30664
Date: Fri, 6 Apr 2007 11:36:41 -0400

 On Apr 6, 11:44am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
 -- Subject: Re: kern/30664

 | [ moved from PR/35675 ]
 | 
 | > | > I am looking for something like solaris' resolvepath(2) which can be
 | > | > used to implement the rest of realpath(3) in userland.
 | > | 
 | > | it isn't necessary to solve these PRs, right?
 | > 
 | > I think that it is a lot easier to handle magiclinks in one place
 | > (kernel since this is where we resolve them now) as opposed to
 | > either introduce a new system call that resolves them, or copy the
 | > code to userland.
 | > 
 | > christos
 | 
 | whatever libc realpath implementation is, there is no way to force
 | applications to use the kernel version.  so, as far as we keep the current
 | semantics of magiclinks, we need to modify readlink(2) anyway.
 | and, if we choose to adapt readlink(2), there is no need to modify realpath.

 Yes, we'll need to modify readlink anyway. I think that the magiclinks
 should be transparent to userland, except possibly to have magic readlink2()
 system call that returns them unresolved. I am not even sure if this is
 necessary.

 | i'm not saying having resolvepath(2) is a bad idea.  (actually, i'm not sure.)
 | i'm merely saying it isn't necessary for these PRs.  don't you agree?

 I agree it is not necessary, but it is a good idea to have nevertheless,
 since most of the code is already present in the kernel.

 christos

>Unformatted:

Home	PR Database Search