为什么用户永远不会使用普通的sudo来启动图形应用程序?
我已阅读社区“RootSudo”文档并对此行感兴趣:
你永远不应该使用普通的sudo来启动图形应用程序作为Root。
为什么? 有什么不同? 请提供一个简单的解释,因为我只是一个普通的桌面用户。
图形应用程序通常将设置和其他用户特定数据存储在用户主文件夹中编写的配置文件中。 应用程序使用的主要机制来确定它们应该使用什么,因为用户的主文件夹是HOME
环境变量 。 (您可以使用echo $HOME
自行检查)。
假设您以root
身份运行gedit
(图形文本编辑器)。 如果你运行sudo gedit
, HOME
将继续指向你的主目录,即使该程序以root
身份运行。 因此, gedit
会将配置文件以root
身份写入您的主目录。 这有时会导致配置文件由root
拥有 ,因此您无法访问 (当您以后以自己而不是root
身份运行程序时)。 这主要发生在应用程序必须创建新配置文件时。 默认情况下,新创建的文件由创建它们的用户拥有(在本例中为root
,而不是您)。
这是你应该使用图形sudo
前端而不是直接sudo
运行图形应用程序的主要原因。 在Ubuntu及其大多数衍生产品(包括Xubuntu和Lubuntu)中,标准图形前端是gksu
/ gksudo
。 在Kubuntu它是kdesudo
。 (这取决于所使用的桌面环境 。)
如果你想直接使用sudo
来运行像gedit
这样的图形应用程序,你可以运行:
sudo -H gedit
-H
标志使sudo
将HOME
设置为指向root
的主文件夹(即/root
)。
它仍然不会通过将.Xauthority
复制到临时文件夹来自动处理.Xauthority
的所有权(这是图形sudo
前端为您处理的另一件事)。 但是在偶然发生.Xauthority
不可访问的事件中,你会收到错误信息,然后你可以通过删除它来解决问题( sudo rm ~/.Xauthority
),因为它会自动重新生成。 因此,保护.Xauthority
的所有权和权限不如保护配置文件的所有权和权限那么重要。
与root
.Xauthority
,当配置文件成为root
,问题并不总是那么明显(因为图形程序经常会运行,但效果不好,并向控制台输出任何有用的错误) 。 而且有时候修复会更麻烦,特别是如果您希望主目录中的一个或多个文件由您以外的其他人拥有 (因为那时您无法通过递归方式将所有chown
修改为文件回复给自己)。
因此, sudo
(至少没有-H
)不应该用于运行图形应用程序, 除非您非常熟悉应用程序的内部工作并确保它不会尝试编写任何配置文件。
简单的说:
这可以防止主目录中的文件归root所有。
在这里阅读。 另外,可能是“gksudo nautilus”和“sudo nautilus”有什么区别?
gksu nautilus
和gksu gedit
的替代方法是使用nautilus-admin
附加组件。 它允许您使用Nautilus浏览文件和目录,然后以root身份打开它们(管理员)。
安装很简单:
sudo apt install nautilus-admin
现在当你在nautilus时,你将有一个额外的选项以管理员身份编辑:
gedit
作为root不允许首选项
当您以root身份运行gedit
,您无法使用您设置为常规用户的制表符,制表符停止,将制表符转换为空格,字体名称,字体大小,换行等。
为了解决这个问题,我编写了脚本sgedit
来inheritance用户首选项并将它们应用到root: 如何将我的root gedit与我的用户gedit的首选项同步?
- 使用
sgedit filename1 filename2 ...
调用sgedit filename1 filename2 ...
- 获取用户的制表位,字体,换行等的gedit设置。
- 升级到
sudo -H
以保留文件所有权,同时获得root权限。 - 如果上次
sudo
已超时,请求密码。 - 获取sudo的gedit设置
- 比较用户和sudo gedit设置之间的差异
- 运行仅在差异上设置的gsettings(将174个设置命令减少到十几个或更少。下次运行时可能只有一两次更改,但通常没有更改。
- 将
gedit
作为后台任务调用,以便终端提示立即重新出现。