[patch] rm can have undesired side-effects

LI Xin delphij at delphij.net
Mon Oct 30 10:06:54 UTC 2006


Joerg Pernfuss wrote:
> On Mon, 30 Oct 2006 19:38:49 +1100
> Peter Jeremy <peterjeremy at optushome.com.au> wrote:
> 
>> I agree.  Doing "rm -P" on a file with multiple links suggests that
>> the user is unaware that there are multiple links.  I don't think
>> that just unlinking the file and issuing a warning is a good solution
>> because it's then virtually impossible to locate the other copy(s)
>> of the file, which remains viewable.
> 
> The only method I know of to find out all the hardlinks to a file is
> 	find /path/to/mountpoint -type f -inum <inode_number>
> 
> The inode number can be obtained via `ls -li' if the file is linked,
> or from the warning the committed patch issues. It surely isn't obvious,
> but neither is it virtually impossible, I'd say.
> 
> The intend of the patch boils down to:
> 	- overwriting a file with multiple links suggets the user is
> 	  unaware of this
> 	- if `rm -rP' is used and all links are under the hierarchy
> 	  that is to be deleted, the file will actually get overwritten
> 	  when the last link is removed
> 	- if rm is not invoked recursive, print the inode number and
> 	  give the user the means to check out what is going on
> 
>> Consider: In FreeBSD, it is possible to create a hardlink to a file if
>> you are not the owner, even if you can't read it.  Mallory may decide
>> to create hardlinks to Alice's files, even if he can't read them today
>> on the off-chance that he may be able to circumvent the protections at
>> a later date.  Unless Alice notices that her file has a second link
>> before she deletes it, when she issues "rm -P", she will lose her link
>> to the file (and her only way of uniquely identifying it) whilst
>> leaving the remaining link to the file in Mallory's control.
> 
> Now it gets tricky. Indeed, one can do this.
> I wasn't aware of that. The second link is created with owner and access
> permissions of the first one and keeps them, even after the first file is
> deleted. So yes, Mallory can deny Alice the ability to remove her file,
> but she can't read it unless she can circumvent the unix file permissions
> system.
> 
> And Alice can search for the inode, link it again and dd(1) a fair share
> of /dev/random over it. Assuming that Alice's find(1) can enter the
> directory in which Mallory linked the file.
> 
> That isn't really that nice, true. But why can i link files that I have
> no business with in the first place? Is there is specific reason?

Another solution is that we follow the OpenBSD behavior and make it
possible for the user to use the historical "feature“, but by default,
if there is hard link then we just do nothing.

Cheers,
-- 
Xin LI <delphij at delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20061030/525354e0/signature.pgp


More information about the freebsd-hackers mailing list