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