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

[Paul Eggert]

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.

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

It may not be a file system issue, but it is a DOS issue.  And there
are similar issues that are file system issues.  For example, whether
file names are case sensitive.  POSIX requires that they must be; many
non-POSIX file systems say they are not.

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