Proposal: removeDirectoryRecursive should not follow symlinks

[Johan Tibell]

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