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@well-typed.com> wrote:
On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer@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@gmail.com> wrote:
>>
>> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell@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@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