NetBSD Problem Report #33375

From www@netbsd.org  Thu Apr 27 05:41:52 2006
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
	id 4FA1963B8EA; Thu, 27 Apr 2006 05:41:52 +0000 (UTC)
Message-Id: <20060427054152.4FA1963B8EA@narn.netbsd.org>
Date: Thu, 27 Apr 2006 05:41:52 +0000 (UTC)
From: chap@NetBSD.org
Reply-To: chap@NetBSD.org
To: gnats-bugs@netbsd.org
Subject: compat_30_sys_getdents sees only top layer of union on -current
X-Send-Pr-Version: www-1.0

>Number:         33375
>Category:       kern
>Synopsis:       compat_30_sys_getdents sees only top layer of union on -current
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 27 05:45:00 +0000 2006
>Last-Modified:  Wed Jan 31 04:05:33 +0000 2007
>Originator:     Chapman Flack
>Release:        3.99.18
>Organization:
>Environment:
NetBSD 3.99.18 NetBSD 3.99.18 (olaf) #4: Mon Apr 24 17:00:37 EDT 2006 xxx@xxx:/usr/src/sys/arch/i386/compile/olaf i386
>Description:
If a union mount is created on a system running -current, 3.0 binaries that call the compat_30 version of getdents(2) can only see entries that are present in the top layer of the union.  They can stat/open/read/write any entry in the union if they know the name, but if it isn't in the top layer they cannot see it.

This may seem like an unlikely scenario, but it comes up naturally
enough in using pkgtools/pkg_comp-like techniques to build 3.0 binaries
on a -current box.
>How-To-Repeat:
Assume a 3.0 /bin and /lib are extracted in /30root

# mkdir t0 t1
# >t0/aaa >t0/bbb
# mount_union t1 t0
# ls t0
aaa bbb
# LD_PRELOAD=/30root/lib/libc.so /30root/bin/ls t0
#

Without the LD_PRELOAD, the files will be seen. The difference is
that the old libc calls the (now) compat_30 getdents(2), while the
new libc calls the current getdents, which seems to work.
>Fix:
Partial workaround: when preparing a 3.0 environment to chroot into,
make the *current* ld.elf_so visible in its /libexec, and the
*current* libc.so* visible in its /lib.  This should cause any of the
dynamically-linked 3.0 binaries that use readdir to be linked with
the current libc and therefore to invoke the current getdents(2).
I've confirmed that 'ls' in the chroot environment properly shows all
entries when this is done.  (Of course the second or third 'ls' incurs
kern/33374, but that seems to be a separate problem--it's repeatable
using only native 3.99 binaries and no chroot. That limits how useful
this workaround is, but this could be a usable workaround once that is
fixed.)

Real fix: teach compat_30_sys_getdents to correctly enumerate entries in unions.  (No clue how much trouble that should be.)

>Release-Note:

>Audit-Trail:
From: chap@netbsd.org (Chapman Flack)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/33375
Date: Fri, 28 Apr 2006 15:00:39 -0400 (EDT)

 My suggested workaround is not practical: some 3.0 binaries still
 preferentially link libc.so.12.128.2 even when 12.140 is present
 and the libc.so and libc.so.12 links point to it. They will link
 12.140 if forced to, but this breaks globbing in sh and pdksh (but
 not csh)--and it's hard to have system stability when the shell is
 broken.

 That means as far as I can tell there is no practical workaround
 and this PR's priority should be increased, as it represents a
 serious regression in COMPAT_30; on real 3.0 systems getdents/
 readdir in union filesystems worked right, as it worked even in 2.0
 and earlier, and it works in -current, but now 3.0 binaries on
 a -current system /will malfunction/ if union filesystems are in
 use. Given that the freshest binary packages available for use on
 -current are those built for 3.0, this regression effectively makes
 the unionfs unusable at all.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, chap@NetBSD.org
Cc: 
Subject: Re: kern/33375
Date: Fri, 28 Apr 2006 15:21:59 -0400

 None of the emulated getdents support unionfs [and whiteouts]. This is
 a more general problem. So far is has not been addressed because of the
 complexity it would introduce to the code.

 christos

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, chap@NetBSD.org
Cc: 
Subject: Re: kern/33375
Date: Fri, 28 Apr 2006 15:29:57 -0400

 Or it might be possible to make the emulation code use vn_readdir() instead
 of using VOP_READIR() directly. If that is possible it will simplify the
 code and at the same time all emulations will be able to deal with unions
 properly.

 christos

>Unformatted:

Home	PR Database Search