一、问题描述

在银河麒麟桌面系统中，如果 /etc/sudoers 文件的权限被误修改为 777，执行 sudo 命令时会直接报错并拒绝执行。典型的报错信息如下：

sudo: /etc/sudoers 可被任何人写 sudo: 没有找到有效的 sudoers 资源，退出 sudo: 无法初始化策略插件

此时，由于 sudo 的安全机制被触发，普通用户无法通过 sudo 提权来修复该文件的权限。

二、原因分析

1、/etc/sudoers 权限机制

sudo 命令在执行前会严格检查 /etc/sudoers 文件的权限。为了防止恶意篡改，该文件的权限必须为 0440（或 0400）。一旦权限变为 777 或其他非安全值，sudo 会认为配置文件已被污染，从而拒绝初始化策略插件并退出。

2、Polkit 认证代理机制

在无法使用 sudo 的情况下，我们通常需要借助 pkexec 来提权修复。但 pkexec 的可用性高度依赖于当前会话中是否存在 Polkit 认证代理（Authentication Agent）：

· 图形界面：UKUI 桌面环境登录后，会自动启动图形认证代理（如 polkit-ukui-authentication-agent-1），因此 pkexec 可以正常弹出密码输入框。

· SSH 远程连接：SSH 建立的是纯文本会话，系统不会自动启动图形认证代理，也没有内置的文本代理。当执行 pkexec 时，polkitd 找不到可用的代理来收集密码，会直接返回 No session for cookie 错误。

三、解决方法

方法一：图形界面下使用 pkexec

如果当前处于完整的图形桌面环境，可以直接使用 pkexec 提权：

pkexec chmod 0440 /etc/sudoers

系统会弹出图形化认证窗口，输入当前用户的密码即可完成修复。

方法二：SSH/终端环境下使用 pkttyagent + pkexec

在 SSH 远程连接或纯终端环境下，直接执行 pkexec 可能会报以下错误：

polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED ==== Error executing command as another user: Not authorized This incident has been reported.

为什么 SSH 下 pkexec 会失败？

前面提到，pkexec 依赖 polkit 认证框架，需要当前会话中有 polkit 认证代理（authentication-agent）来收集密码。图形桌面登录后，UKUI 桌面环境会自动启动 polkit-ukui-authentication-agent-1 等图形认证代理，所以完整的图形环境下 pkexec 可以直接用。但 SSH 会话是独立的文本会话，不会启动图形 polkit 代理，也没有内置的文本代理，所以 polkitd 找不到可用的认证代理来收集密码，直接返回 No session for cookie。

解决方案：

手动启动 Polkit 的文本认证代理 pkttyagent，并通过管道将其与 pkexec 关联：

pkttyagent --process $$ | pkexec chmod 0440 /etc/sudoers

命令拆解：

· pkttyagent：Polkit 的文本模式认证代理，负责在终端中弹出密码输入提示。

· --process $$：指定当前 Shell 进程（$$ 为当前进程 PID），让代理为当前会话提供认证服务。

· | ：管道符，将认证代理与 pkexec 的请求关联起来。

· pkexec chmod 0440 /etc/sudoers：pkexec 不依赖 /etc/sudoers 文件，因此即使该文件权限损坏也能正常执行提权操作。

执行成功后，可以用 ls -l /etc/sudoers 验证权限是否已恢复：

ls -l /etc/sudoers

# 输出应为：-r--r----- 1 root root 901 ... /etc/sudoers

然后验证 sudo 是否恢复正常：

sudo -l

# 如果能正常输出当前用户的 sudo 权限列表，说明修复完成

四、原理深入：Polkit 认证代理机制详解

1、Polkit 架构说明

Polkit 的权限认证由两部分组成：

· polkitd：系统级守护进程（/usr/lib/policykit-1/polkitd），负责权限策略的判断和授权决策。

· authentication-agent：会话级代理，负责向用户收集密码并将结果返回给 polkitd。

2、工作流程如下：

· pkexec 向 polkitd 发起授权请求；

· polkitd 判断需要管理员认证；

· polkitd 通过 D-Bus 通知当前会话的认证代理弹出密码输入界面；

· 认证代理收集密码后返回给 polkitd；

· 认证通过后，pkexec 才真正以 root 身份执行命令。

3、为什么图形界面可以、SSH 不行

· 图形桌面：登录后，桌面环境（如 UKUI、GNOME、KDE）会自动启动对应的图形认证代理（如 polkit-ukui-authentication-agent-1），polkitd 随时可以调用它来弹窗收集密码。

· SSH 会话：是独立的文本会话，没有图形环境，也不会自动启动任何认证代理。polkitd 在 SSH 会话中找不到代理，自然无法完成认证。

4、如何查看当前会话是否有代理

可以通过以下命令检查当前系统中运行的 Polkit 认证代理：

ps aux | grep -i polkit

或者更精确地查找认证代理进程：

pgrep -a authentication-agentpgrep -a pkttyagent

常见的代理进程名包括：

· polkit-gnome-authentication-agent-1：（GNOME 桌面）

· polkit-kde-authentication-agent-1：（KDE 桌面）

· polkit-ukui-authentication-agent-1：（银河麒麟 UKUI 桌面）

· pkttyagent：（文本模式代理）

如果 ps aux 输出中只有 polkitd 守护进程，而没有 authentication-agent 或 pkttyagent 进程，就说明当前会话缺少认证代理。

五、知识扩展

1、/etc/sudoers 文件作用

/etc/sudoers 是 sudo 命令的核心配置文件，定义了哪些用户或用户组可以以超级用户（root）或其他用户的身份执行命令，以及可以执行哪些命令。通过合理配置 /etc/sudoers，可以实现权限的细粒度控制，避免滥用 root 权限带来的安全风险。

2、权限不能设 777 的原因

将 /etc/sudoers 文件权限设置为 777（即 rwxrwxrwx）会带来严重的安全隐患：

· 安全风险：777 权限意味着任何用户（包括非特权用户）都可以读取、修改甚至删除该文件。攻击者可能利用这一漏洞提升自己的权限，获得 root 访问权限，从而完全控制系统。

· sudo 的设计限制：sudo 命令在运行时会对 /etc/sudoers 文件的权限进行严格检查。如果文件权限过于宽松（如 777），sudo 会拒绝执行并报错，提示权限不安全。这是 sudo 的一种自我保护机制。

· 最小权限原则：Linux 系统遵循最小权限原则，即仅授予必要的权限。/etc/sudoers 文件通常应设置为 440（-r--r-----），仅允许 root 用户读取和写入，其他用户只能读取。

3、正确权限设置与 visudo 建议

· /etc/sudoers 的正确权限应为 0440（-r--r-----），所有者为 root:root。

· 永远不要直接编辑 /etc/sudoers，应使用 sudo visudo 命令。visudo 会在保存前进行语法检查，并在编辑时自动锁定文件，防止多人同时修改导致配置损坏。

· 也千万不要用 chmod 777 /etc/sudoers 来"图方便"：这会导致 sudo 彻底不可用。

修复权限后，可使用以下命令验证 sudo 是否恢复正常：

sudo -lsudo su

六、总结

/etc/sudoers 权限被误改为 777 是运维中常见的"自锁"问题。修复的核心思路是绕过 sudo，使用 pkexec 提权。在图形界面下，pkexec 可直接使用；而在 SSH 环境下，由于没有 polkit 认证代理，需要手动启动 pkttyagent 作为文本认证代理，才能完成 pkexec 的密码收集流程。理解 Polkit 的认证代理机制，不仅能解决本次问题，也能帮助运维人员在遇到类似提权故障时快速定位原因。