Proposal: removeDirectoryRecursive should not follow symlinks

[Austin Seipp]

On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer at gmail.com> wrote:
> In case some people don't understand just how horrible this is: imagine a
> privileged user uses this to erase a user's home directory. It could easily
> hit a symbolic link to a critical system directory and hose the whole
> machine.

I think it's potentially even worse than that: this subtle behavior
could easily be abused for this exact scenario by a hostile entity.
Imagine a scenario where an attacker may have permission to place a
symlink somewhere that a privileged process recursively removes; then
your / (or any number of things) goes 'boom'. This could easily happen
through a combination of a race condition (say, placing junk files in
/tmp you later remove, and the attacker races to place the symlink
there) and an improper umask setting. Or if the attacker simply may be
part of a group that allows access to something a program will remove,
etc etc.

I agree this behavior is fundamentally wrong, and I'm strongly +1 on
changing the existing behavior, which I think is the only sane thing
to do. Otherwise any existing callers of this function in old code
could very easily do The Wrong Thing if they don't get the memo.

I have no opinion on warnings or adding a function that preserves the
old behavior.

> On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
>>
>> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>>
>>> Aside: can we look at what other languages with similar functions do?
>>
>>
>> You will find that essentially all other implementations do the right
>> thing and not follow symlinks, because the other behavior is a severe bug. I
>> really do not understand why anyone believes the current behavior is
>> defensible.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/