NetBSD Problem Report #36227

From mark@mcs.vuw.ac.nz  Fri Apr 27 01:40:07 2007
Return-Path: <mark@mcs.vuw.ac.nz>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 70B6F63B960
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 27 Apr 2007 01:40:07 +0000 (UTC)
Message-Id: <200704270140.l3R1e4RC024220@city-art.mcs.vuw.ac.nz>
Date: Fri, 27 Apr 2007 13:40:04 +1200 (NZST)
From: Mark Davies <mark@mcs.vuw.ac.nz>
Reply-To: mark@mcs.vuw.ac.nz
To: gnats-bugs@NetBSD.org
Subject: new emul namei problem with symlinks
X-Send-Pr-Version: 3.95

>Number:         36227
>Category:       kern
>Synopsis:       new emul namei problem with symlinks
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 27 01:45:00 +0000 2007
>Last-Modified:  Sun Apr 29 17:25:01 +0000 2007
>Originator:     Mark Davies
>Release:        NetBSD 4.99.18
>Organization:
Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
>Environment:


System: NetBSD lap3.mcs.vuw.ac.nz 4.99.18 NetBSD 4.99.18 (MCS_LAPTOP) #4: Fri Apr 27 12:41:12 NZST 2007  mark@lap3.mcs.vuw.ac.nz:/local/SAVE/build.obj/local/src/src/sys/arch/i386/compile/MCS_LAPTOP i386
Architecture: i386
Machine: i386
>Description:
	The new namei handling of emul paths fails to handle symlinks pointing
	out of the /emul tree correctly.
	This was first noticed while testing the fix for PR 36196 but really
	has nothing to do with that PR so I'm opening a new one to track it.

>How-To-Repeat:
	# echo "hello" > /tmp/test
	# ln -s /tmp/test /emul/linux/etc/foo
	# /emul/linux/bin/cat /etc/foo
	/emul/linux/bin/cat: /etc/foo: No such file or directory

>Fix:


>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36227: new emul namei problem with symlinks
Date: Fri, 27 Apr 2007 09:00:56 +0200

 On Fri, Apr 27, 2007 at 01:45:00AM +0000, Mark Davies wrote:
 > 	# echo "hello" > /tmp/test
 > 	# ln -s /tmp/test /emul/linux/etc/foo
 > 	# /emul/linux/bin/cat /etc/foo
 > 	/emul/linux/bin/cat: /etc/foo: No such file or directory

 I think this is a feature of the new code, not a bug (think links
 to /lib in /usr/lib when doing netbsd32 emul)

 What should work is:

   cd /emul/linux/etc && ln -s /../tmp/test foo

 Martin

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36227: new emul namei problem with symlinks
Date: Fri, 27 Apr 2007 08:26:14 +0100

 On Fri, Apr 27, 2007 at 01:45:00AM +0000, Mark Davies wrote:
 > >Number:         36227
 > >Category:       kern
 > >Synopsis:       new emul namei problem with symlinks
 > 	
 > 	
 > >Description:
 > 	The new namei handling of emul paths fails to handle symlinks pointing
 > 	out of the /emul tree correctly.
 > 	This was first noticed while testing the fix for PR 36196 but really
 > 	has nothing to do with that PR so I'm opening a new one to track it.
 > 	
 > >How-To-Repeat:
 > 	# echo "hello" > /tmp/test
 > 	# ln -s /tmp/test /emul/linux/etc/foo
 > 	# /emul/linux/bin/cat /etc/foo
 > 	/emul/linux/bin/cat: /etc/foo: No such file or directory

 Unfortunately there are two different place such a symlink might
 need to reference.  If, as I did, you mount an existing netbsd i386
 install onto /emul/netbsd32 of an amd64 system, then you want absolute
 symbolic links found inside the emulation root to stay inside the root.
 Otherwise you fall foul when /usr/libexec/ld.elf_so is a symlink to
 /libexec/ld.elf_so (and similarly with links from /usr/lib/foo to /lib/foo).

 So I made it such that absolute symlinks stay inside the emulation root
 (when found with an absolute pathname) unless the name is "/../foo".

 (So you may also want to make /emul/linux/etc/mtab a link to /../proc/mounts)

 	David

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

From: Mark Davies <mark@mcs.vuw.ac.nz>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/36227: new emul namei problem with symlinks
Date: Sat, 28 Apr 2007 10:00:39 +1200

 On Friday 27 April 2007, David Laight wrote:
 >  So I made it such that absolute symlinks stay inside the emulation
 > root (when found with an absolute pathname) unless the name is
 > "/../foo".
 >
 >  (So you may also want to make /emul/linux/etc/mtab a link to
 > /../proc/mounts)

 OK, I'd missed the /.. trick.  That should probably be mentioned in 
 UPDATING or somewhere.

 The compat_linux and compat_osf1 manual pages (at least) have the 
 following in their bugs section:

      Pathnames pointed to by symbolic links are not looked up in the
      shadow root when running a Linux executable.  This is not
      consistent.

 That needs to be updated.


 Also while playing with this I saw the following which seems odd:

   # cd /emul/linux/etc/
   # echo hello > bar
   # echo bye > /etc/bar
   # ln -s /etc/bar foo
   # /emul/linux/bin/cat /etc/foo
   hello
   # /emul/linux/bin/cat foo
   bye


 cheers
 mark

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36227: new emul namei problem with symlinks
Date: Sun, 29 Apr 2007 18:28:11 +0100

 On Fri, Apr 27, 2007 at 10:05:04PM +0000, Mark Davies wrote:
 >  
 >  Also while playing with this I saw the following which seems odd:
 >  
 >    # cd /emul/linux/etc/
 >    # echo hello > bar
 >    # echo bye > /etc/bar
 >    # ln -s /etc/bar foo
 >    # /emul/linux/bin/cat /etc/foo
 >    hello
 >    # /emul/linux/bin/cat foo
 >    bye

 I've been trying to think of an easy way of coding it so that relative
 lookups that hit absolute symlinks inside the emulated root are
 treated the same as absolute lookups.
 I think it needs a check for vn_isunder() in the symlink path and
 (yet) another revamp of what is tested to determine that the emulated
 root should be considered.

 	David

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

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.