cvs commit: src/bin/rm rm.1 rm.c

[LI Xin]

Simon 'corecode' Schubert wrote:
> Victor Balada Diaz wrote:
>> On Sat, Nov 04, 2006 at 06:26:39PM -0800, Matthew Dillon wrote:
>>> dillon      2006/11/04 18:26:39 PST
>>>
>>> DragonFly src repository
>>>
>>>   Modified files:
>>>     bin/rm               rm.1 rm.c   Log:
>>>   Sync our rm -P option with OpenBSD - if the file has a hardlink count
>>>   greater then one do not overwrite it or remove it, and issue a
>>> warning.
>>
>> If you use -P you know what you're doing, or at least if you use -f
>> with -P. DragonFly by default allows any user to do a hard link to
>> a file he doesn't own, so if you really want to delete file contents
>> you must be able to.
> 
> I think in any case, rm -P should remove setuid/gid bits from the file,
> because if your intention originally was to completely remove the file,
> and suddenly it (and its links) stay arround, still with setuid set, it
> could be quite bad.
> 
> The situation I have in my head is (courtesy of vbd):
> 
> /home symlink to /usr/home
> 
> eviluser$ ln /usr/bin/lpr /usr/home/eviluser/tmp/lpr-faulty
> # yay.  lpr-faulty is setuid root
> 
> # security advisory: vuln in lpr
> root# rm -P /usr/bin/lpr
> root#  # eh?  warning?  whatever, never find out where the link is
> root# rm /usr/bin/lpr
> root# install -mode 1555 /root/fixed-lpr /usr/bin/lpr
> 
> # one month later
> eviluser$ exploit ~/tmp/lpr-fault

While I think this is purely the administrator's fault (one should first
do chmod 000 *before* trying to fix the files), it might be advisable
that there is some way to get the old behavior, if the administrator
really what he is doing.  This can be archived by counting -P's numbers
(e.g. -PP for old behavior), or by determining whether -f is specified,
as we did on FreeBSD.  For now I tend to agree that -P should not exist
in the first place, though...

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

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 249 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/commits/attachments/20061105/a1412e06/attachment-0020.obj>