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

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


reply via email to

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