[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 07:11:23 +0100 (CET)

On Fri, 29 Dec 2006, Paul Eggert wrote:

Mikulas Patocka <address@hidden> writes:

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?

Then it might not be so easy, of course.  But going back to your
original point: what I was objecting to was the claim that "POSIX
specifies something that is unimplementable".  Obviously stable file
serial numbers are implementable.  They just aren't easily
implementable if one chooses the wrong implementation strategy.

How would you implement them for FAT filesystem?

I know about these possibilities:
* inode number is location of dirent on disk --- changes when file is
        moved to different directory
* inode number is the first cluster --- survives rename but changes when
        file is truncated and written again
* build a memory table that translates inode numbers to files on disk ---
        the table would need (disk_size/32) entries (this is the maximum
        of files on FAT filesystem)
* inode number is assigned when loading inode to memory --- changes when
        inode is released from memory due to high virtual memory stress
        (this is what Linux does --- inode numbers seem stable and unique,
        but they change for non-open files when the system is under load)

Do you have any other idea how to get stable inode number on FAT?

There are a lot of packages that will break (sometimes subtly) on file
systems that lack stable file serial numbers

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

You can't seriously expect all these applications to change their
documentation to say "watch out; this may not work with nonstandard
file systems"!  That would be sort of like saying "watch out! this
won't work if your computer is not plugged in."

Generally speaking, warnings about problems with nonstandard file
systems belong with the file systems, not with applications.

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

Yes, that's true.  And I wouldn't recommend using these file systems
for heavy-duty use in POSIX environments where reliability is
important.  Their nonstandard behavior breaks too many things.

I guess they are OK for less-important duty, since people use them.
But we cannot wave a magic wand and declare them reliable and
standard; clearly they're not.

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?"

That's up to Jim, but such behavior doesn't sound all that useful to
me.  For light duty applications like "cp foo bar", "cp" should work
just fine.

It won't if they randomly happen to have the same inode.

It also doesn't work on FAT --- cp first stats, then opens, then fstats --- if you are on FAT filesystem on Linux and VM decides to discard the inode before open and reload it on open, cp will see different inode number and report error.

Also, it'd be a pain to maintain the list of nonstandard
file systems.  People are always coming up with new ones.

If you can think of a way for "cp" to detect the problem cheaply, at
run time, then it would probably be worth putting in a warning.
Ideally this would involve no new system calls.  For example, if "cp"
discovers two files with different types (e.g., one a directory and
one a regular file) but the same file serial number, then that would
be an indication of the bug.  I'm waving my hands a bit here, but I
hope you get the idea.

What really scares me is that this posix-requirements are getting tighter and tighter --- for example OS/2 doesn't have inode numbers too and so Eberhard Mattes just takes an integer, increases it on each stat or fstat call and returns it as inode number --- and guess what, GNU utilities of that era work on it fine.

I wouldn't even try to compile the current version on OS/2, seeing how many inode number checks it has. And recently you added all directories to hash (to detect hardlinked directories), breaking non-posix filesystem even more.


reply via email to

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