Proposal: removeDirectoryRecursive should not follow symlinks

[David Feuer]

One approach (extreme, perhaps) would be to simply write

{-# DEPRECATED removeDirectoryRecursive #-}
removeDirectoryRecursive = error "This function was horribly dangerous and
has been removed. Use _____ instead."
On Jan 5, 2015 8:22 PM, "Eric Mertens" <emertens at gmail.com> wrote:

> I'm concerned that changing the behavior of the existing function would
> make it too easy to write vulnerable programs when compiled with older
> GHCs. Having a new safe function along with a deprecation warning on the
> old one would clue people in and avoid functionality varying
> subtly/dangerously based on the compiler used.
>
> On Mon, Jan 5, 2015, 5:17 PM Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> Let me make a wider comment about backwards compatibility. Many
>> successful programming languages (e.g. Java) *never* break backwards
>> compatibility. They deprecate (and only if the old API is too error prone
>> for the programmer) and add a new API. In my opinion breaking backwards
>> compatibility is almost never worth it*. Our libraries are already full of
>> #ifdefs and maintaining our core libraries (which I maintain some of) is a
>> headache because the code gets worse every time we "clean it up".
>>
>> * And it's only worth it sometimes because we're still a relatively small
>> language, by usage.
>>
>> On Mon, Jan 5, 2015 at 8:08 PM, Austin Seipp <austin at well-typed.com>
>> wrote:
>>
>>> 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/
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/0bede5c5/attachment-0001.html>