问题描述
我读过the comunity “RootSudo” documentation,对这一行感兴趣:
You should never use normal sudo to start graphical applications as Root.
为什么?有什么不同?请提供一个简单的解释,因为我只是一个普通的桌面用户。
最佳解决办法
图形应用程序通常将设置和其他user-specific数据存储在用户home folder内写入的配置文件中。主要机制应用程序用于确定它们应该用作用户的主文件夹的是HOME
environment variable。 (您可以使用echo $HOME
自行检查)。
假设你正在运行gedit
(一个图形化文本编辑器)作为root
。如果您运行sudo gedit
,HOME
将继续指向您的主目录,即使该程序正在以root
运行。因此,gedit
会将配置文件写入root
到主目录。这个配置文件中的will sometimes result由root
为owned,因此为inaccessible to you(当您稍后以自己的身份运行程序而不是root
时)。这主要发生在应用程序必须创建新的配置文件时。新创建的文件默认由创建它们的用户拥有(在这种情况下,root
,而不是您)。
这是您使用图形sudo
前端运行图形应用程序而不是直接运行sudo
的主要原因。在Ubuntu及其大部分衍生产品(包括Xubuntu和Lubuntu)中,标准图形前端是gksu
/gksudo
。在Kubuntu它是kdesudo
。 (这取决于正在使用的desktop environment。)
如果您想直接使用sudo
运行gedit
等图形应用程序,则可以运行:
sudo -H gedit
-H
标志使sudo
将HOME
设置为指向root
的主文件夹(即/root
)。
这仍然不会自动处理.Xauthority
的所有权,方法是将其复制到临时文件夹(这是图形sudo
前端为您处理的另一件事)。但在.Xauthority
无法访问的罕见事件中,您会收到错误消息,然后您可以通过删除它(sudo rm ~/.Xauthority
)修复问题,因为它会自动重新生成。因此,保护.Xauthority
的所有权和权限不如保护配置文件的所有权和权限。
与root
拥有的.Xauthority
不同,当配置文件拥有root
时,问题并不总是那么明显(因为图形程序经常运行,但不能很好地工作,并向控制台输出任何有用的错误)。有时候修复这个问题更麻烦一些,特别是当你想让你的主目录中的一个或多个文件被别人以外的人所拥有时(因为那样你就无法简单地通过递归方式修复它)chown
ing you all文件回到你自己)。
因此,不应该使用sudo
(至少不使用-H
)来运行图形应用程序,除非您非常熟悉该应用程序的内部工作方式,并且确定它没有尝试写入任何配置文件。
次佳解决办法
简单的说:
This prevents files in your home directory becoming owned by root.
阅读它here。此外,可能是What is the difference between “gksudo nautilus” and “sudo nautilus”?的副本