coc*_*mac 2 root privileges rfkill
我在这个答案的最后看到了这样的说法：
PS：我不知道为什么 rfkill 在以非特权用户身份运行时起作用。在我的 Mint 上，它没有 setuid 或 setgid 位。
我很好奇，查看了我的 Arch 系统。这是我的系统上的内容sudo和rfkill外观。文件大小和日期已被省略。看起来没有 setuid 位rfkill（为了比较，有一个sudo）。
$ /usr/bin/env ls -lah $(which sudo) $(which rfkill)
-rwxr-xr-x 1 root root [OMITTED] /sbin/rfkill
-rwsr-xr-x 1 root root [OMITTED] /sbin/sudo
有趣的是，运行rfkill以禁用和启用无线访问的工作方式如此处所述，即使我是rfkill从我的帐户运行（即，不是 asroot和 not withsudo或类似）。
如何不rfkillrequire ，因为通常启用/禁用硬件的命令需要以特权root运行？root
现代 Linux 系统生态系统（可能基于systemd）/dev可以在物理登录时（即：在键盘前）更改条目的访问权限。
人们可以比较 的所有权/dev/rfkill。例如，在 Debian 12 系统上查看 UID 1000 登录本地（物理）会话的用户时：
$ echo $UID
1000
$ getfacl -n /dev/rfkill
getfacl: Removing leading '/' from absolute path names
# file: dev/rfkill
# owner: 0
# group: 106
user::rw-
user:1000:rw-
group::rw-
mask::rw-
other::r--
因此，这里额外的 ACL 授予所有者对设备文件的访问权限：
user:1000:rw-
如果不在用户实际登录的部分（有sleep 5时间切换到带有登录提示的控制台），则此 ACL 会被删除（如果存在）：
$ echo $UID
1000
$ getfacl -n /dev/rfkill
getfacl: Removing leading '/' from absolute path names
# file: dev/rfkill
# owner: 0
# group: 106
user::rw-
user:1000:rw-
group::rw-
mask::rw-
other::r--
只要链接的内核驱动程序没有特别限制设备文件上 ACL 之外的进一步访问权限或所有权，这适用于使用它的应用程序，无需额外的权限。
运行（作为 root 会更好，但结果并没有真正改变）：
inotifywait -m -r -e attrib /dev
并切换两次，到带有登录提示的控制台并返回，以获得一个想法，通常也这样做：
/dev/snd/)/dev/dri/)/dev/cdrom可能是一些可移动设备文件（例如： ...的目标）/dev/kvm)这可能不反映默认值，但提供了一个想法。
快速搜索在 Linux 上的 Multi-Seat中的systemd文档中找到了此条目：
请注意，logind管理许多设备类上的 ACL ，以便只要用户在其上有活动会话，就允许用户代码访问连接到席位的设备节点。这对于应用程序来说基本上是透明的。
当使用systemd进行管理时，至少有两个组件发挥作用：
udevd标记系统上出现的符合条件的设备TAG+="uaccess"
根据经验，该列表可以通过类似的内容找到（没有/lib符号链接的系统/usr/lib也应该在 中搜索/usr/lib/udev/rules.d）：
grep -rw uaccess /etc/udev/rules.d /lib/udev/rules.d
在其他结果中，可以在以下位置找到 rfkill 的一行/lib/udev/rules.d/70-uaccess.rules：
KERNEL=="rfkill", SUBSYSTEM=="misc", TAG+="uaccess"
Logind跟踪用户席位更改（当然除了创建之外），并在用户席位处于活动状态时更改先前用uaccess标记的设备的 ACL
对于小细节：seat_set_active()-> seat_apply_acls()-> devnode_acl_all()，稍后检查uaccess标记。