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