Re: [patch] rm can have undesired side-effects

Peter Jeremy wrote:
On Sun, 2006-Oct-29 18:11:54 -0800, perryh@xxxxxxxxxxxxxx wrote:
I think a very strong case can be made that the *intent* of -P --
to prevent retrieval of the contents by reading the filesystem's
free space -- implies that it should affect only the "real" removal
of the file, when its blocks are released because the link count
has become zero.
...
In this interpretation, "rm -P" when the link count exceeds 1 is
an erroneous command.

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. I believe this is a security
hole.

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.

I think Peter is right here. I recently patched the -P option to error
out if a file is unwritable. I think that is the correct behavior here
too. If the file is not removed, then it is correct for rm to exit
with an rc > 0. Another poster mentioned the case of using rm in a
script, or for a large directory where this kind of warning might get
missed, which is one of the reasons I think it needs to exit with an
error code.

My suggestion would be to change warnx() to errx(), and drop the
return(1); from that patch. If there are no objections I'll do it
myself if no one gets to it first.

In any case I think that this is a good addition to the code, and I'm
glad that this issue was raised.

Doug

--

This .signature sanitized for your protection
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"