NetBSD Problem Report #14470

Received: (qmail 10631 invoked from network); 5 Nov 2001 15:50:31 -0000
Message-Id: <20011105155014.2B4C511112@www.netbsd.org>
Date: Mon,  5 Nov 2001 07:50:14 -0800 (PST)
From: gavan@coolfactor.org
Sender: nobody@netbsd.org
Reply-To: gavan@coolfactor.org
To: gnats-bugs@gnats.netbsd.org
Subject: find fails with an error on certain CDROMs
X-Send-Pr-Version: www-1.0

>Number:         14470
>Category:       bin
>Synopsis:       find fails with an error on certain CDROMs
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 05 15:51:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Thu Nov 08 21:04:01 +0000 2001
>Originator:     Gavan Fantom
>Release:        1.5/i386 and 1.5.2/arm32
>Organization:
>Environment:
NetBSD theforce 1.5 NetBSD 1.5 (THEFORCE) #15: Fri Oct  5 22:11:36 BST 2001     gavan@theforce:/usr/src/sys/arch/i386/compile/THEFORCE i386
>Description:
find fails with an error while traversing the directory structure of one particular CDROM which I have. While this *may* be a problem with the CD, or an interaction with a non-standard extension to ISO9660 (the CDROM is aimed at Acorn users, so uses CDFS extensions), find shouldn't bomb out entirely here, as this results in the daily security script amongst others failing in strange ways.

This problem occurs both on 1.5/i386 and 1.5.2/arm32.
>How-To-Repeat:
Using the "RISC OS Programmer's Reference Manuals" CDROM, from RISC OS Ltd.

bash-2.04$ mount | grep mnt
/dev/cd0d on /mnt type cd9660 (local, read-only)
bash-2.04$ find /mnt >/dev/null
find: fts_read: No such file or directory

>Fix:
Unknown as yet; maybe find should be modified to change this condition to a non-fatal error?

I will be happy to test ideas, bugfixes etc.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: ws 
State-Changed-When: Tue Nov 6 15:03:53 PST 2001 
State-Changed-Why:  
Analyzed a dump of the offending CD. 

From: Wolfgang Solfrank <ws@tools.de>
To: gavan@coolfactor.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/14470: find fails with an error on certain CDROMs
Date: Wed, 07 Nov 2001 00:02:53 +0100

 gavan@coolfactor.org wrote:
 > 
 > >Number:         14470
 > >Category:       bin
 > >Synopsis:       find fails with an error on certain CDROMs
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    bin-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Nov 05 07:51:00 PST 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Gavan Fantom
 > >Release:        1.5/i386 and 1.5.2/arm32
 > >Organization:
 > >Environment:
 > NetBSD theforce 1.5 NetBSD 1.5 (THEFORCE) #15: Fri Oct  5 22:11:36 BST 2001     Hi,

 gavan@theforce:/usr/src/sys/arch/i386/compile/THEFORCE i386
 > bash-2.04$ find /mnt >/dev/null
 > find: fts_read: No such file or directory
 > 
 > >Fix:
 > Unknown as yet; maybe find should be modified to change this condition to a non-fatal error?

 OK, so after Gavan sent me some dumps of the offending CD, it's obvious
 that the problem
 is that the directory /APPS/!PDF/BIN is pretty empty; meaning that it
 only has an entry for
 ".", but no entry for ".." (which, of course, is invalid for a 9660
 filesystem).  The result
 is that find, after descending into this directory, doesn't find a way
 out of it.

 IMHO, it would be inappropriate to try to fix this in our cd9660 fs
 implementation, or in the
 find command.

 However, what I'd like to get fixed is the error message.  It would be
 far more informative
 if it said:

 find: ..: No such file or directory

 instead of giving the name of the routine that gets the error (which
 probably doesn't tell
 anything to the casual user).

 Ciao,
 Wolfgang
 -- 
 ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800

From: Gavan Fantom <gavan@coolfactor.org>
To: Wolfgang Solfrank <ws@tools.de>
Cc: <gnats-bugs@gnats.netbsd.org>
Subject: Re: bin/14470: find fails with an error on certain CDROMs
Date: Wed, 7 Nov 2001 11:08:25 +0000 (GMT)

 On Wed, 7 Nov 2001, Wolfgang Solfrank wrote:

 > IMHO, it would be inappropriate to try to fix this in our cd9660 fs
 > implementation, or in the find command.

 I would be inclined to disagree here. This PR originated because the
 the CDROM being mounted overnight caused spurious messages from the
 nightly security script claiming setuid additions. This is because the
 find failed one night and succeeded the next. Due to the failure, a number
 of setuid files were not recorded.

 If an attacker were able to create an invalid directory such as the one
 found on this CDROM, this would be a way to hide setuid files. vnd
 springs to mind as an easy way to do this. Heck, the attacker could even
 post a copy of the Programmers Reference Manual CD to the sysadmin of the
 target system.

 Given that there are things (like the security script) that critically
 depend on find working across the entire system, it would seem appropriate
 that find have some way of recovering gracefully and continuing its search
 despite bad directories.

 One way in which this could be done is by setting FTS_NOCHDIR when calling
 fts_open. Here's a patch to add an option '-n' to find which sets this
 flag, so that programs which rely on find not bailing out can use this
 flag.

 Index: main.c
 ===================================================================
 RCS file: /cvsroot/basesrc/usr.bin/find/main.c,v
 retrieving revision 1.16
 diff -r1.16 main.c
 92c92
 < 	while ((ch = getopt(argc, argv, "HLPXdf:hsx")) != -1)
 ---
 > 	while ((ch = getopt(argc, argv, "HLPXdf:hnsx")) != -1)
 119a120,122
 > 			break;
 > 		case 'n':
 > 			ftsoptions |= FTS_NOCHDIR;

 If this is applied, the security tools at least should be modified to use
 this new flag.

 -- 
 Gillette - the best a man can forget


From: Wolfgang Solfrank <ws@tools.de>
To: Gavan Fantom <gavan@coolfactor.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/14470: find fails with an error on certain CDROMs
Date: Thu, 08 Nov 2001 20:38:32 +0100

 Gavan Fantom wrote:
 > 
 > On Wed, 7 Nov 2001, Wolfgang Solfrank wrote:
 > 
 > > IMHO, it would be inappropriate to try to fix this in our cd9660 fs
 > > implementation, or in the find command.
 > 
 > I would be inclined to disagree here. This PR originated because the
 > the CDROM being mounted overnight caused spurious messages from the
 > nightly security script claiming setuid additions. This is because the
 > find failed one night and succeeded the next. Due to the failure, a number
 > of setuid files were not recorded.

 Hmm, well, you are touching on a bigger problem here.  There are surely
 quite a lot
 of ways to even _crash_ the system by mounting some invalid filesystem. 
 And yes,
 this problem does need to be addressed, especially in the light that the
 system now
 allows for arbitrary users to mount filesystems (albeit not in the
 standard
 configuration anymore).

 This could be done in the kernel, but this would more or less amount to
 including
 fsck for the various filesystems in the kernel, which would be dead code
 most of
 the time.  Another approach would be to somehow let fsck sign a
 filesystem in some
 way that tells the kernel that it is safe to mount it.  BTW, keep in
 mind that we
 don't even have a fsck utility for most of the supported filesystems
 (including cd9660).

 That said, your patch may work around the problem with your particular
 CD (though,
 not having the CD, I haven't tested it), but I'm not sure whether this
 (this meaning
 to address every little problem with a cute hack which just fixes this
 one) is the
 right approach to the bigger problem.

 Ciao,
 Wolfgang
 -- 
 ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800

From: Gavan Fantom <gavan@coolfactor.org>
To: Wolfgang Solfrank <ws@tools.de>
Cc: <gnats-bugs@gnats.netbsd.org>
Subject: Re: bin/14470: find fails with an error on certain CDROMs
Date: Thu, 8 Nov 2001 21:00:50 +0000 (GMT)

 On Thu, 8 Nov 2001, Wolfgang Solfrank wrote:

 > This could be done in the kernel, but this would more or less amount to
 > including
 > fsck for the various filesystems in the kernel, which would be dead code
 > most of
 > the time.  Another approach would be to somehow let fsck sign a
 > filesystem in some
 > way that tells the kernel that it is safe to mount it.  BTW, keep in
 > mind that we
 > don't even have a fsck utility for most of the supported filesystems
 > (including cd9660).

 ffs already has such a "signature" in the form of the clean bit, although
 this kind of idea is really meaningless in the case of read-only media.
 And it also doesn't seem appropriate to have to run fsck on insertion of
 media. Maybe a better solution would be that the filesystem code take care
 to preserve certain assumptions that userland code depends on, like that
 every directory should have a parent.

 > That said, your patch may work around the problem with your particular
 > CD (though,
 > not having the CD, I haven't tested it),

 It does work with this CD, yes.

 > but I'm not sure whether this
 > (this meaning
 > to address every little problem with a cute hack which just fixes this
 > one) is the
 > right approach to the bigger problem.

 It may not solve the bigger problem, but it's pretty standard practise to
 turn off optimisations in cases where they fail. According to the manpage
 for the fts functions:

   "As a performance optimization, the fts functions change directories as
    they walk the file hierarchy."

 The patch I supplied provides an option to find(1) to turn off this
 optimisation. As for fixing every little problem individually, I'm not
 sure that there are many in this case. There just aren't many programs out
 there that walk the entire filesystem, and most of those invoke find(1) to
 do it. Also, the impact of failure is different when you consider differet
 programs. /bin/sh can't cd to .. from within the bad directory (whereas
 bash can - bash is obviously storing the pathname already) but that is
 only a minor inconvenience. It doesn't have a knock on effect of aborting
 a large operation, and certainly doesn't cause spurious security warnings
 to be generated.

 I would therefore be inclined to suggest that at the very least
 administrators should be given the ability to turn off this optimisation
 if it bites them. This is, after all, why the patch adds an option to
 find(1) rather than changing the default behaviour. Once that is done,
 solving the deeper issue is indeed worthwhile.

 -- 
 Gillette - the best a man can forget

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