隨着GHC 8.0.2如果我在開始此發出警告ghci的在我的項目目錄中創建一個.ghci文件模式644：項目具體ghci的初始化文件的權限警告
*** WARNING: .ghci is writable by someone else, IGNORING!
Suggested fix: execute 'chmod go-w .ghci'
在採用這個建議，在啓動時ghci然後我們得到：
*** WARNING: . is writable by someone else, IGNORING!
Suggested fix: execute 'chmod go-w .'
通過此建議使警告消失。這很好，但是這很乏味和煩人，特別是因爲使用堆棧，默認創建的目錄權限並不是ghci看起來想要的。
爲什麼添加一個.ghci文件會導致這種行爲，ghci擔心的是什麼？沒有本地目錄.ghci文件ghci不會抗議權限。
可悲的是，我現在發現這是已經拒絕修復的問題：
爲什麼加入.ghci文件導致此行爲，究竟是什麼這是ghci中擔心？沒有本地目錄.ghci文件ghci不會抗議權限。
我猜你的umask已設置，以便所有新創建的文件在默認情況下都是組可寫的。這允許系統中的任何用戶寫入它。一些GHCi命令允許運行任何命令。因此，只要啓動GHCi，任何可以寫入您的.ghci文件的人都將能夠基本上劫持您的帳戶。
GHCi試圖通過拒絕解釋其他人可寫的文件來防止此攻擊。這是否應該是這種情況是有爭議的。
一方面，更改權限很容易，只能重做一次，除非您重新生成.ghci。即使您自動重新生成它，您也可以使用可以爲您做chmod的腳本。或者，更好的辦法是更嚴格地設置你的umask，以便新文件獲得嚴格的權限（我認爲你應該使用umask 002） - 這需要爲每個shell運行一次，或者可以放在shell初始化文件中。另一方面，GHCi在這裏有點謹慎，與大多數unix不同，它使用（用於？）爲您提供所有需要掛起自己的繩索，正如俗話所說。也許一個標誌ghci --ignore-config-permissions將是有用的。
雖然我認爲ghc不應該指示我如何管理我個人系統的安全性，但我現在明白ghci可以用'！'運行任意shell命令。命令，並且如果本地.ghci包含在外部下載的軟件包中，這些命令可能會在不知不覺中注入到會話中。所以設計決策正試圖避免這種風險。我同意設置一個更嚴格的umask就是答案，但人們往往不會在單個用戶工作站上自動執行此操作。 – andro