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