RE: Problem with .ghci (fwd)

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.
To subvert GHCi's paranoia, just put this in your $HOME/.ghci: :def source IO.readFile :source ./.ghci (for extra marks, you could make it check that `pwd` /= $HOME, that you hadn't already loaded ./.ghci). Cheers, Simon PS. quite embarrassingly, it appears that GHCi just goes ahead and reads $HOME/.ghci even if the permissions are unsafe. Time for another release methinks, before GHCi gets its first CERT advisory :)

"Simon Marlow"
To subvert GHCi's paranoia, just put this in your $HOME/.ghci:
:def source IO.readFile :source ./.ghci
(for extra marks, you could make it check that `pwd` /= $HOME, that you hadn't already loaded ./.ghci).
Aha! That's the ideal solution I was hoping for: if I locally disable the normal loading of .ghci files in the current directory, each user can effectively define their own security policy in their ~/.ghci file using this trick. Thanks! Given this, could I suggest a compile-time option to globally disable reading .ghci files in the current directory (whilst still reading ~/.ghci), for sites where files might not be trusted even where they're writable only by the current user? (E.g. if I mount a random CD on this box, it'll come up under my UID with 600 permissions, but I wouldn't necessarily want to trust a .ghci file on there.) Or is this too specialised a case to merit a configure script option? Cheers, Chris.
participants (2)
-
Chris Webb
-
Simon Marlow