NetBSD Problem Report #42420

From www@NetBSD.org  Mon Dec  7 05:52:41 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 51B7963C484
	for <gnats-bugs@gnats.netbsd.org>; Mon,  7 Dec 2009 05:52:41 +0000 (UTC)
Message-Id: <20091207055241.24F4E63C483@www.NetBSD.org>
Date: Mon,  7 Dec 2009 05:52:41 +0000 (UTC)
From: austinenglish+netbsd@gmail.com
Reply-To: austinenglish+netbsd@gmail.com
To: gnats-bugs@NetBSD.org
Subject: $ORIGIN undefined on NetBSD
X-Send-Pr-Version: www-1.0

>Number:         42420
>Category:       kern
>Synopsis:       $ORIGIN undefined on NetBSD
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 07 05:55:00 +0000 2009
>Closed-Date:    Mon May 27 02:53:22 +0000 2019
>Last-Modified:  Mon May 27 02:53:22 +0000 2019
>Originator:     Austin English
>Release:        5.0.1
>Organization:
>Environment:
NetBSD 6.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 01:39:11 UTC 2009  builds@b8.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386
>Description:
$ORIGIN is undefined on NetBSD, see:
http://bugs.winehq.org/show_bug.cgi?id=20907
and
http://mail-index.netbsd.org/netbsd-users/2009/07/29/msg004188.html
and
http://source.winehq.org/git/wine.git/?a=blob;f=configure;h=275a1efb356decee100161a7853600004175cfaf;hb=HEAD#l6762
>How-To-Repeat:
Try to compile wine from git (not ports, though any version should do it, without using the workarounds in ports).
>Fix:

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Mon, 7 Dec 2009 12:40:30 +0100

 It would probably help if you would provide a small, simple, reproducable
 test case that demonstrated the problem. The PR does not even make clear
 why you think this is a kernel problem.

 Martin

From: Austin English <austinenglish@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	austinenglish+netbsd@gmail.com
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Wed, 17 Mar 2010 14:26:44 -0500

 On Mon, Dec 7, 2009 at 5:45 AM, Martin Husemann <martin@duskware.de> wrote:
 > The following reply was made to PR kern/42420; it has been noted by GNATS=
 .
 >
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
 > =C2=A0 =C2=A0 =C2=A0 =C2=A0netbsd-bugs@netbsd.org
 > Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
 > Date: Mon, 7 Dec 2009 12:40:30 +0100
 >
 > =C2=A0It would probably help if you would provide a small, simple, reprod=
 ucable
 > =C2=A0test case that demonstrated the problem. The PR does not even make =
 clear
 > =C2=A0why you think this is a kernel problem.

 It's needed by:
 http://source.winehq.org/git/wine.git/?a=3Dcommitdiff;h=3D5ed59015b290c7c12=
 38c7d08cacc299f0aa151e

 to help Wine find its libraries. I found this
 http://mail-index.netbsd.org/netbsd-users/2009/07/29/msg004188.html,
 which led me to believe it's a kernel problem.

 --=20
 -Austin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Tue, 23 Mar 2010 18:03:04 +0000

 On Wed, 17 Mar 2010 14:26:44 -0500, austinenglish@gmail.com wrote:
  > It's needed by:
  > http://source.winehq.org/git/wine.git/?a=3Dcommitdiff;h=3D5ed59015b290c7c12=
  > 38c7d08cacc299f0aa151e
  >
  > to help Wine find its libraries.

 The autoconf test is broken. It only checks that you can stuff
 arbitrary garbage into the rpath, not that anything will work as
 expected. This will fail, perhaps silently, on any system that doesn't
 have $ORIGIN implemented, which I believe is quite a few of them.

 Please get that fixed in Wine.

 (The kernel issue in NetBSD is that $ORIGIN only gets set for programs
 invoked with an absolute pathname.)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Austin English <austinenglish@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	austinenglish+netbsd@gmail.com, Alexandre Julliard <julliard@winehq.org>
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Tue, 23 Mar 2010 16:26:48 -0600

 On Tue, Mar 23, 2010 at 12:05 PM, David Holland
 <dholland-bugs@netbsd.org> wrote:
 > The following reply was made to PR kern/42420; it has been noted by GNATS=
 .
 >
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
 > Date: Tue, 23 Mar 2010 18:03:04 +0000
 >
 > =C2=A0On Wed, 17 Mar 2010 14:26:44 -0500, austinenglish@gmail.com wrote:
 > =C2=A0> It's needed by:
 > =C2=A0> http://source.winehq.org/git/wine.git/?a=3D3Dcommitdiff;h=3D3D5ed=
 59015b290c7c12=3D
 > =C2=A0> 38c7d08cacc299f0aa151e
 > =C2=A0>
 > =C2=A0> to help Wine find its libraries.
 >
 > =C2=A0The autoconf test is broken. It only checks that you can stuff
 > =C2=A0arbitrary garbage into the rpath, not that anything will work as
 > =C2=A0expected. This will fail, perhaps silently, on any system that does=
 n't
 > =C2=A0have $ORIGIN implemented, which I believe is quite a few of them.
 >
 > =C2=A0Please get that fixed in Wine.
 >
 > =C2=A0(The kernel issue in NetBSD is that $ORIGIN only gets set for progr=
 ams
 > =C2=A0invoked with an absolute pathname.)

 From Alexandre Julliard - Wine maintainer:
 Failing silently is fine (and expected), we set LD_LIBRARY_PATH as
 fallback. Refusing to load the binary is broken. The configure check is
 here to determine what works at compile time, it doesn't need to (and
 cannot) check that $ORIGIN will behave correctly at run time.

 (also cc'ing him, with his permission).

From: Austin English <austinenglish@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Tue, 10 Jul 2012 16:23:05 -0500

 On Mon, Dec 7, 2009 at 5:45 AM, Martin Husemann <martin@duskware.de> wrote:
 > The following reply was made to PR kern/42420; it has been noted by GNATS.
 >
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
 >         netbsd-bugs@netbsd.org
 > Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
 > Date: Mon, 7 Dec 2009 12:40:30 +0100
 >
 >  It would probably help if you would provide a small, simple, reproducable
 >  test case that demonstrated the problem. The PR does not even make clear
 >  why you think this is a kernel problem.
 >
 >  Martin
 >

 ############
 austin@debian-work:~$ cat test.sh
 #!/bin/sh
 set -e
 set -x
 cat > foo.c <<__EOF
 #include <stdio.h>
 int main(void)
 {
     return 0;
 }
 __EOF

 gcc -o a.out -fPIC -Wl,--rpath,\$ORIGIN/../lib foo.c
 ./a.out
 rm -f a.out foo.c

 ############

 on Debian, works fine, on NetBSD (5.1.2):
 execname not specified in AUX vector: No such file or directory

 -- 
 -Austin

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	austinenglish+netbsd@gmail.com
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Tue, 10 Jul 2012 18:36:25 -0400

 On Jul 10,  9:25pm, austinenglish@gmail.com (Austin English) wrote:
 -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD

 Look for #ifdef notyet in kern_exec.c and get rid of them

 christos

From: David Laight <david@l8s.co.uk>
To: 
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Wed, 11 Jul 2012 07:53:37 +0100

 On Tue, Jul 10, 2012 at 06:36:25PM -0400, Christos Zoulas wrote:
 > On Jul 10,  9:25pm, austinenglish@gmail.com (Austin English) wrote:
 > -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
 > 
 > Look for #ifdef notyet in kern_exec.c and get rid of them
 > 
 > christos

 Hmmm....
 Maybe the kernel should be keeping a vnode reference of the directory
 a program was loaded on.
 Then something like open("//$ORIGIN/<path>"...) could be used.
 Or maybe openat() could have some magic fd numbers.

 Of course, you need to DTRT when a program chroots.
 If $ORIGIN is inside the chroot, $ORIGIN relative paths should still work
 (and if outside, must not).

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Wed, 11 Jul 2012 13:07:34 -0400

 On Tue, 10 Jul 2012 22:40:07 +0000 (UTC)
 christos@zoulas.com (Christos Zoulas) wrote:

 >  Look for #ifdef notyet in kern_exec.c and get rid of them

 I didn't yet check the code, but of interest:
 http://www.h-online.com/open/news/item/Root-privileges-through-vulnerability-in-GNU-C-loader-1110182.html

 We must be sure that like for LD_PRELOAD and LD_LIBRARY_PATH, ORIGIN be
 disabled for setuid and setgid binaries.
 -- 
 Matt

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Wed, 11 Jul 2012 18:24:18 +0100

 On Wed, Jul 11, 2012 at 05:10:05PM +0000, Matthew Mondor wrote:
 >  
 >  We must be sure that like for LD_PRELOAD and LD_LIBRARY_PATH, ORIGIN be
 >  disabled for setuid and setgid binaries.

 I suspect that $ORIGIN is ok for suid programs provided that the saved
 path contains no symlinks or is a direct reference to the actual directory
 the program binary was loaded from.

 Saving the string passed to exec certainly isn't good enough.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	austinenglish+netbsd@gmail.com
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Wed, 11 Jul 2012 14:02:52 -0400

 On Jul 11,  5:10pm, mm_lists@pulsar-zone.net (Matthew Mondor) wrote:
 -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD

 |  I didn't yet check the code, but of interest:
 |  http://www.h-online.com/open/news/item/Root-privileges-through-vulnerability-in-GNU-C-loader-1110182.html
 |  
 |  We must be sure that like for LD_PRELOAD and LD_LIBRARY_PATH, ORIGIN be
 |  disabled for setuid and setgid binaries.

 It is indeed disabled.

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Thu, 12 Jul 2012 18:05:20 +0000

 On Wed, Jul 11, 2012 at 07:00:09AM +0000, David Laight wrote:
  >  > On Jul 10,  9:25pm, austinenglish@gmail.com (Austin English) wrote:
  >  > -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
  >  > 
  >  > Look for #ifdef notyet in kern_exec.c and get rid of them

 It still won't always work, though.

 Since the wine people apparently believe they don't need to check for
 the feature before using it, only checking if the linker understands
 how to try, perhaps it should be disabled in binutils until we can
 come up with a complete solution.

  >  Hmmm....
  >  Maybe the kernel should be keeping a vnode reference of the directory
  >  a program was loaded on.
  >  Then something like open("//$ORIGIN/<path>"...) could be used.
  >  Or maybe openat() could have some magic fd numbers.

 That has its problems, but would probably be better. Unfortunately,
 the interface has been handed to us from outside, and it came from an
 environment that doesn't have a problem with pinning half the
 filesystem permanently in the namecache.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Thu, 12 Jul 2012 18:22:44 +0000

 On Thu, Jul 12, 2012 at 06:10:06PM +0000, David Holland wrote:
  >   >  > On Jul 10,  9:25pm, austinenglish@gmail.com (Austin English) wrote:
  >   >  > -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
  >   >  > 
  >   >  > Look for #ifdef notyet in kern_exec.c and get rid of them
  >  
  >  It still won't always work, though.
  >  
  >  Since the wine people apparently believe they don't need to check for
  >  the feature before using it, only checking if the linker understands
  >  how to try, perhaps it should be disabled in binutils until we can
  >  come up with a complete solution.

 Actually, I take it back, the only thing the cited Wine configure test
 actually checks for is whether rpaths are accepted (which should be
 the case on any ELF system) and whether they're allowed to contain $.

 Since rpaths are apparently allowed to contain anything (even control
 characters) the configure test is absolutely worthless. There's no
 point attempting to disable $ORIGIN in binutils since it looks as if
 binutils doesn't know or need to know anything about it.

 As I said some time back, the configure test should be changed
 upstream to actually test for the feature, in which case the problem
 goes away.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Austin English <austinenglish@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	austinenglish+netbsd@gmail.com
Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
Date: Wed, 18 Jul 2012 11:32:17 -0700

 On Thu, Jul 12, 2012 at 11:25 AM, David Holland
 <dholland-bugs@netbsd.org> wrote:
 > The following reply was made to PR kern/42420; it has been noted by GNATS.
 >
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
 > Date: Thu, 12 Jul 2012 18:22:44 +0000
 >
 >  On Thu, Jul 12, 2012 at 06:10:06PM +0000, David Holland wrote:
 >   >   >  > On Jul 10,  9:25pm, austinenglish@gmail.com (Austin English) wrote:
 >   >   >  > -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
 >   >   >  >
 >   >   >  > Look for #ifdef notyet in kern_exec.c and get rid of them
 >   >
 >   >  It still won't always work, though.
 >   >
 >   >  Since the wine people apparently believe they don't need to check for
 >   >  the feature before using it, only checking if the linker understands
 >   >  how to try, perhaps it should be disabled in binutils until we can
 >   >  come up with a complete solution.
 >
 >  Actually, I take it back, the only thing the cited Wine configure test
 >  actually checks for is whether rpaths are accepted (which should be
 >  the case on any ELF system) and whether they're allowed to contain $.
 >
 >  Since rpaths are apparently allowed to contain anything (even control
 >  characters) the configure test is absolutely worthless. There's no
 >  point attempting to disable $ORIGIN in binutils since it looks as if
 >  binutils doesn't know or need to know anything about it.
 >
 >  As I said some time back, the configure test should be changed
 >  upstream to actually test for the feature, in which case the problem
 >  goes away.
 >
 >  --
 >  David A. Holland
 >  dholland@netbsd.org
 >

 From http://bugs.winehq.org/show_bug.cgi?id=20907:
 Like I explained in that bug, we don't care if $ORIGIN doesn't work, but it
 shouldn't cause the binary to fail to load, and that's a NetBSD bug. It should
 just ignore an invalid rpath and continue with the normal library search.

 -- 
 -Austin

State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 27 May 2019 02:53:22 +0000
State-Changed-Why:
I am told $ORIGIN works now.


>Unformatted:

Home	PR Database Search