<p dir="ltr">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.</p>
<br><div class="gmail_quote">On Mon, Jan 5, 2015, 5:17 PM Johan Tibell <<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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".<div><br></div><div>* And it's only worth it sometimes because we're still a relatively small language, by usage.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 8:08 PM, Austin Seipp <span dir="ltr"><<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
> In case some people don't understand just how horrible this is: imagine a<br>
> privileged user uses this to erase a user's home directory. It could easily<br>
> hit a symbolic link to a critical system directory and hose the whole<br>
> machine.<br>
<br>
</span>I think it's potentially even worse than that: this subtle behavior<br>
could easily be abused for this exact scenario by a hostile entity.<br>
Imagine a scenario where an attacker may have permission to place a<br>
symlink somewhere that a privileged process recursively removes; then<br>
your / (or any number of things) goes 'boom'. This could easily happen<br>
through a combination of a race condition (say, placing junk files in<br>
/tmp you later remove, and the attacker races to place the symlink<br>
there) and an improper umask setting. Or if the attacker simply may be<br>
part of a group that allows access to something a program will remove,<br>
etc etc.<br>
<br>
I agree this behavior is fundamentally wrong, and I'm strongly +1 on<br>
changing the existing behavior, which I think is the only sane thing<br>
to do. Otherwise any existing callers of this function in old code<br>
could very easily do The Wrong Thing if they don't get the memo.<br>
<br>
I have no opinion on warnings or adding a function that preserves the<br>
old behavior.<br>
<span><br>
> On Jan 5, 2015 6:44 PM, "Brandon Allbery" <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Aside: can we look at what other languages with similar functions do?<br>
>><br>
>><br>
>> You will find that essentially all other implementations do the right<br>
>> thing and not follow symlinks, because the other behavior is a severe bug. I<br>
>> really do not understand why anyone believes the current behavior is<br>
>> defensible.<br>
>><br>
>> --<br>
>> brandon s allbery kf8nh                               sine nomine<br>
>> associates<br>
>> <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>
>> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a><br>
>> unix, openafs, kerberos, infrastructure, xmonad<br>
>> <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a><br>
>><br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
>><br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
><br>
<br>
</span><span><font color="#888888">--<br>
Regards,<br>
<br>
Austin Seipp, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
</font></span><div><div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</blockquote></div>