[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SECURITY] Re: PATCH: rm -rf and readdir bug in coreutils-6.7

From: Mikulas Patocka
Subject: Re: [SECURITY] Re: PATCH: rm -rf and readdir bug in coreutils-6.7
Date: Sat, 30 Dec 2006 22:53:51 +0100 (CET)

On Sat, 30 Dec 2006, Jim Meyering wrote:

Mikulas Patocka <address@hidden> wrote:
There are a lot of packages that will break (sometimes subtly) on file
systems that lack stable file serial numbers: coreutils, diffutils,
git, tar, the list goes on for quite a ways.  I'm afraid the only
current answer to this problem is "don't do that then".
(I'm quoting Linus Torvalds in <http://lkml.org/lkml/2005/4/8/236>.)

So tell users not to do it. How should they otherwise find?

The most scary thing is that these filesystems most-time work and break
randomly, when inode numbers colide.

For people who care about robustness, this is a good argument
for avoiding those file systems.

However, let's be more precise.  These file systems do not reuse
i-node numbers "randomly", but rather only under extreme memory
pressure, and then only for files that are not in use.

That said, copy.c could be implemented in a way that would work
better in the face of those constraints.  Such a rewrite would
be welcome also for the fact that it would eliminate the current
PATH_MAX limitation.  Volunteers welcome :)  Same for ls.c.

There are two separate issues on this: changing ino_t (which is unavoidable on FAT) and non-unique ino_t (which is unavoidable on CODA).

Would you really dare to accept a patch that prints
"cp: error, your filesystem is not posix compliant, to prevent possible
data damage, coreutils refuses to operate on it?" on non-conforming
filesystems? (AFS, SMB, CODA, FAT ...)

Coreutils 5 used to work (at least if nlink == 1 they didn't care about
inode numbers), the new code in coreutils 6 to prevent directory loops
breaks on non-posix filesysmtes.

coreutils-5.x even had support for systems with no inode
numbers.  However, since then, the bar has been raised: there
were fundamental limitations associated with the chdir-based
approach.  Fortunately, I've been able to transition to a more
robust approach that is also more efficient: use openat and the
other *at functions -- it also permits a thread-safe remove.c.
However, since we continue to support systems that lack native
openat support, and since fts.c still supports the legacy non-fd
interface, some bits of code are more convoluted.

Luckily for most people, the coreutils-6.x programs work just
fine, even on non-posix file systems.  If you find a way to make
a coreutils program malfunction consistently in an environment
that's not _too_ contrived, please let us know.  The ideal would
be to provide a script that can be used as a non-interactive
test case, to be run only on systems with required file system
type and/or permissions (e.g., root).

I don't have time to write it now, but the reproducible way for cp failure on FAT on Linux could be:

create directory tree with many small files
use cp -a on that tree
stop it
run other unrelated big program (no touching the tree at all -- just
        allocate memory to remove inodes from cache)
resume cp
--- if the files are small, the probability that cp is stopped after stat and before open could be non-infinitesimal.

BTW. could it be possible to change POSIX on this issue? (i.e. specify that general file manipulation tools must work on foreign non-posix filesystems, specify a statvfs flag meaning that filesystem has colliding/unstable inode numbers) Is it bureaucraticly achievable? --- standarts should be done to support reliable operation but it looks like this ino_t uniqueness does just the opposite.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]