Peter Jeremy wrote:
> On Sun, 2006-Oct-29 18:11:54 -0800, [EMAIL PROTECTED] 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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
