[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 04:40:58 +0100 (CET)

Mikulas Patocka <address@hidden> writes:

If POSIX specifies something that is unimplementable (unique stable
inode numbers) the question is why to rely on it?

But it's easily implementable, if your file system was written with
POSIX in mind.

And if someone else designed it --- like FAT or SMB?

In many cases the POSIX folks had to decide whether to make
concessions to non-Unix practice.  For example, should POSIX allow a
distinction between text and binary files, which is pretty much a
requirement for DOS-ish file systems?

This is not filesystem issue, DOS can work with files with '\n' newlines too.

As a general rule, the POSIX standardizers decided to stick with the
traditional Unix semantics when there was a clear clash with non-Unix
systems.  Inode numbers is one of those cases; newline representation
is another.

In other words: what utility should I use to *reliably* copy directory
tree on smb filesystem? (current cp will choke if it finds two
directories with the same ino).

smbclient should be able to do it, no?  (Admittedly it might be a bit
awkward, but that's often what happens when you start dealing with
nonstandard systems.  :-)

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.

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.


reply via email to

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