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:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.