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

[Jim Meyering]

Mikulas Patocka <address@hidden> wrote:
> On Sat, 30 Dec 2006, Paul Eggert wrote:
>> Mikulas Patocka <address@hidden> writes:
>>
>>> BTW. could it be possible to change POSIX on this issue?
>>
>> I very much doubt it.  POSIX deliberately does not specify the
>> behavior of non-POSIX file systems, or of programs operating on
>> non-POSIX file systems.  That's out of scope, just as it'd be out of
>> scope for (say) the US Congress to legislate French foreign policy.
>> (Not that they haven't tried....)
>
> The question is then why to follow POSIX? It is a shame that such a simple
> operation as copying a file from floppy diskette or usb stick has a race
> condition ... thanks to standartization committee.

Since most file systems *do* conform to POSIX when it comes
to inode numbers, it is only natural that tools like those in
gnulib and coreutils take advantage of whatever integrity
checks they can, to better protect against abuse and/or misuse.

If removing the inode-related checks would make programs less
useful on reliable file systems, or if testing whether to remove
those checks at run time would impose a noticeable cost on systems
that do have useful inode numbers, then why should we bother?
The risk of your race condition is very low and affects only
2nd (3rd?) class file systems like FAT.

However, it is possible to rewrite copy.c so that there
is no race between the stat and open calls for regular files.
However, it's a big and thankless job.

That would make a good student project.
Ideally, if someone does this, they will take the time to
ensure better test coverage _first_.