[nycbug-talk] Safety Expansion for FreeBSD rm(1)

[Nathan Boeger]

Steven Kreuzer wrote:
> On Tue, Oct 02, 2007 at 02:22:46PM -0400, Nathan Boeger wrote:
>   
>> Steven Kreuzer wrote:
>>     
>>> Greetings-
>>>
>>> I am reading through the freebsd-current mailing list and I stumbled upon a
>>> proposed patch that I thought was rather interesting
>>>
>>> Basically, is a patch to rm that first reads ~/.rm before actually removing
>>> anything to make sure that what you are trying to delete isn't "protected"
>>>
>>> Example, if I did rm -rf ~ /bin (when I really wanted ~/bin) it would check
>>> to make sure that /bin and ~ are allowed to be removed.
>>>
>>> I am kinda on the fence about this, but think it could be a useful way to
>>> protect yourself from yourself
>>>
>>> Project Page: http://people.freebsd.org/~daichi/safety-rm/
>>> eMail thread on freebsd-current: 
>>> http://marc.info/?l=freebsd-current&m=119072708632143&w=2
>>>
>>> What do you think?
>>>
>>>  
>>>       
>> So here is a few questions:
>>
>> 1. What if  someone aliased: cat /dev/null > ~/.rmrc?
>>     
>
> So you end up with a 0B regular file.
>
> while (fgets(line, sizeof(line), fp) != NULL)
>
> File is just opened and closed and rm continues on. This would almost be the
> same as having no ~/.rm file.
>   
Exactly, so some meanie could easily blow your file away. Or worse you 
could fat finger it and never know. So it offers little to no help.
>> 2. What if rm is has setuid bit on it for some strange reason? Then 
>> would your ~/.rmrc still be read?
>>     
>
> rm is just reading the file, not executing it.
>
>   
No, what I mean is the binary rm has setuid not the ~/.rmrc file.
>> 3. What if I dd if=/dev/random of=~/.rmrc  and make it some huge blob. 
>> Could this expose a buffer overun?
>>
>>     
> Anything is possible. Buffer overflows happens. You use best practices to
> try and avoid them, but if they happen, you find the cause and patch it.
>
>   
Agreed, but going out of your way to potentially create them for no real 
benefit does not seem practical.
>> 4. Will rm need to check if the ~/.rmrc is hard or soft linked?
>>
>>     
>
> I just took a closer look at the patch. The original author only checks to
> make sure the file is there, and if it is, makes sure it is owned by the user
> and they have read access to it. Might make sense to throw in some checks to
> make sure it is a regular file.
>
>   
Good idea, so what if the user is issuing rm -fR /dir/* that has a lot 
of files. Would you then check every time? Or would it fail for all? 
What about: for i in `ls /dir/' do rm $i; done?

And if it took a lot of time to delete all those files and someone 
updated the ~/.rmrc before it was complete then what? Would that change 
not be reflected in the current rm process?
>> 5. Would rm never be allowed to remove `/.rmrc or would you need to list 
>> it inside its own file?
>>
>>     
>
> This might break the time continuum and can result to a time
> paradoxon. Don't be suprised.
>
>   
Or worse it could rip a whole into fluidic space and unleash species 8472!