Proposal: removeDirectoryRecursive should not follow symlinks

[Eric Mertens]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/405c587e/attachment.html>