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

[Jim Meyering]

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.

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