場景 1：允許普通用戶掛載外部USB驅動器

這個場景完美體現了從“命令控制”到“動作控制”的范式轉變。

1. 使用 sudo / doas 實現（傳統方式）

思路： 找到掛載命令（mount, udisksctl），授權用戶執(zhí)行它。

• sudo 配置 (visudo)：

  bash

  # 授權用戶 alice 執(zhí)行 mount 命令來掛載 /dev/sdb1 這個特定設備（不靈活）
  alice ALL=(root) /usr/bin/mount /dev/sdb1 /mnt/usb
  
  # 或者，更危險地：授權 alice 掛載任何設備（極度不安全！）
  alice ALL=(root) /usr/bin/mount
  
  # 更現代的做法：授權使用 udisksctl 命令（桌面環(huán)境實際在后臺使用的）
  alice ALL=(root) /usr/bin/udisksctl mount -b /dev/sdb1

  缺點： 非常不靈活。設備名（/dev/sdb1）會變，且授權整個 mount 命令風險極高。

• doas 配置 (/etc/doas.conf)：

  bash

  # 和 sudo 類似，語法更簡潔
  permit alice as root cmd /usr/bin/udisksctl mount -b /dev/sdb1

  缺點： 同樣存在靈活性和安全性的問題。

2. 使用 polkit 實現（現代方式）

思路： 定義“允許普通用戶掛載可移動存儲設備”這個動作。

• Polkit 規(guī)則文件 (/etc/polkit-1/rules.d/10-allow-mount.rules)：

  javascript

  polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" &&
        subject.isInGroup("users")) {
      return polkit.Result.YES;
    }
  });

  或者，更簡單的方法： 大多數發(fā)行版已經自帶了默認規(guī)則，通常位于 /usr/share/polkit-1/rules.d/，你只需要確認或輕微修改即可。

-------------------

場景 2：允許普通用戶重啟系統

這是一個經典需求，對比非常明顯。

1. 使用 sudo / doas 實現

思路： 授權 reboot 或 systemctl reboot 命令。

• sudo 配置：

  bash

  # 授權 wheel 組用戶執(zhí)行重啟命令
  %wheel ALL=(root) /usr/bin/systemctl reboot

• doas 配置：

  bash

  # 授權 wheel 組用戶執(zhí)行重啟命令
  permit :wheel as root cmd /usr/bin/systemctl reboot

用戶體驗： 在終端中需要輸入 sudo systemctl reboot 或 doas systemctl reboot，然后輸入自己的密碼。

2. 使用 polkit 實現

思路： 定義“允許控制臺本地用戶或某些組用戶重啟系統”這個動作。

• Polkit 規(guī)則文件 (/etc/polkit-1/rules.d/10-allow-reboot.rules)：

  javascript

  polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.reboot" ||
        action.id == "org.freedesktop.login1.reboot-multiple-sessions") {
      if (subject.isInGroup("wheel")) {
        return polkit.Result.YES;
      }
      // 或者更精細：允許本地活動會話用戶無需密碼
      // if (subject.active && subject.local) {
      //   return polkit.Result.YES;
      // }
    }
  });

用戶體驗：

1. 圖形界面 (GUI)： 在GNOME/KDE的菜單中點擊“重啟”，不會彈出密碼框，直接執(zhí)行。體驗無縫。

2. 命令行 (CLI)： 用戶可以直接使用 systemctl reboot，同樣不會提示密碼?；蛘呤褂?nbsp;pkexec systemctl reboot，這會彈出一個圖形化的認證對話框。

對比分析：

• sudo/doas： 只能在命令行使用，且體驗一致：需要輸入密碼。

• polkit： 提供了統一的后端策略，同時服務于圖形前端和命令行后端，并能根據上下文（用戶組、會話位置）提供不同的認證體驗。

• --------------------場景 3：允許開發(fā)用戶綁定到特權端口（如80端口）

• Web開發(fā)常見需求，需要綁定1024以下的端口。

  1. 使用 sudo / doas 實現（危險?。?/h4>

  思路： 授權用戶以 root 權限運行 Node.js、Python 等服務器程序。

  • sudo 配置：

    bash

    # 授權用戶 devuser 以 root 身份運行 /usr/bin/node
    devuser ALL=(root) /usr/bin/node /path/to/app.js

    巨大風險： 這意味著這個腳本擁有了完全的 root 權限，可以執(zhí)行任何操作，極度危險。

  2. 使用 setcap 實現（更安全的方式，但仍屬 sudo/doas 范疇）

  思路： 給特定的二進制文件授予特定權限，而不是給用戶。

  • 命令行：

    bash

    # 授予 node 二進制文件綁定到特權端口的能力
    sudo setcap 'cap_net_bind_service=+ep' /usr/bin/node

    優(yōu)點： 比直接以 root 運行整個程序安全得多。
    缺點： 權限被授予了整個二進制文件。任何用戶都可以用 /usr/bin/node 來綁定特權端口。

  3. 使用 polkit 實現（不適用）

  結論： 對于這種“給程序文件本身賦予能力”的場景，不是 Polkit 的設計目標。Polkit 管理的是用戶動作的授權。

  本場景最佳實踐： 使用 setcap 是一種改進，但最好的方式是使用反向代理（如 Nginx）或將服務配置為通過 systemd socket 激活，從而完全避免讓用戶進程直接處理特權端口。