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

[Mikulas Patocka]

> Mikulas Patocka <address@hidden> wrote:
> > BTW. looking at the code leads me to another observation --- all those
> > security checks against 'rm'-vs-'mv' race break apart if the attacker is
>
> Thank you for bringing this up.  However, note that such systems are not
> POSIX-compliant, since (as you must well know) POSIX requires unique inode
> numbers.  There are several places in the coreutils where this requirement
> is assumed, mainly for security and directory-cycle detection, but also
> for the relatively new --preserve-root option.  Relaxing it would not be
> trivial.  It's just that I'm not (yet?) convinced doing so is desirable.

It's quite bad.

Those unique inode numbers are unimplementable in certaion filesystems or 
operating systems (smb or coda can have collisions; fat inode number 
changes in rename; you can mount filesystem over NFS from 64-bit system on 
an old 32-bit system; on Windows, you have reliable file identifier only 
as long as the file is open).

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

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

Mikulas