Re: Proposal: removeDirectoryRecursive should not follow symlinks

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 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 wrote:

...

On Mon, Jan 5, 2015 at 5:51 PM, David Feuer 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" wrote:

...

On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries