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