| explicitly tell ghci that they're okay! Hand-holding w.r.t. | 'insecure' file permissions has a nasty habit of becoming a | nuisance in unusual cases the original authors hadn't thought of. :-( Constructive suggestions for how to improve are welcome. What we are trying to avoid is obvious trojan horses, where X can persuade Y's ghci to do rm *.*. This is bad. Simon
"Simon Peyton-Jones"
| explicitly tell ghci that they're okay! Hand-holding w.r.t. | 'insecure' file permissions has a nasty habit of becoming a | nuisance in unusual cases the original authors hadn't thought of. :-(
Constructive suggestions for how to improve are welcome. What we are trying to avoid is obvious trojan horses, where X can persuade Y's ghci to do rm *.*. This is bad.
Quite. I don't think there is a solution that's going to work everywhere and the current version is simple and effective for most people. I fixed my InteractiveUI.hs to ignore g+w if the group that owns the file is my group, but that's completely wrong at sites which have some users in shared groups. I guess there's no reliable general test for a UPG except with local knowledge. There's certainly no fix for the shared directory situation that isn't also going to let dubious .ghci files through elsewhere. Unfortunately I can't think of any better option than to leave it as it is with a note in the manual indicating the default permissions-checking behaviour is and where to look in the source to change it if necessary. Cheers, Chris.
Simon Peyton-Jones wrote:
| explicitly tell ghci that they're okay! Hand-holding w.r.t. | 'insecure' file permissions has a nasty habit of becoming a | nuisance in unusual cases the original authors hadn't thought of. :-(
Constructive suggestions for how to improve are welcome. What we are trying to avoid is obvious trojan horses, where X can persuade Y's ghci to do rm *.*. This is bad.
How about verifying an untrusted .ghci file by looking up its MD5 hash in a list of "approved" hashes? The verification would occur only if the user provides an approval list (or lists?) in $HOME/.ghci (which should be writable only by that user): :add_auto_ghci_list $HOME/.ghci-approval Then, when the user should happen to encounter the dreaded *** WARNING: ./.ghci is writable by someone else, IGNORING! he could inspect the suspect .ghci file, and (if it meets approval) tack its md5sum unto his approval list to tell ghci that autoloading this particular file is okay: md5sum .ghci >> $HOME/.ghci-approval Thoughts: * Fairly simple to use. * Imposes no overhead if you don't use it. * Eliminates the possibility of running an untrusted .ghci file that is writable by someone else. (Unless *you* approve it, it won't run. If the file changes, you must re-approve it.) BUT * Seems a bit roundabout. How does that sound? Cheers, Tom
participants (3)
-
Chris Webb -
Simon Peyton-Jones -
Tom Moertel