在某些情况下可能值得禁止用户执行任何二进制文件(我想这可能是针对特权提升漏洞的对策之一)。但在很多情况下,普通用户能够执行自己的二进制文件,那么如果用户自己编写和编译fdisk 或类似的东西怎么办?真的,您不想禁止用户运行fdisk。您只想禁止fdisk 或任何其他程序以某种方式修改系统状态。所以普通用户真的可以执行 fdisk:
$ fdisk --help
Usage:
fdisk [options] <disk> change partition table
fdisk [options] -l [<disk>] list partition table(s)
...
普通用户实际上不能做的是执行受限操作:
$ fdisk /dev/sda
Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
fdisk: cannot open /dev/sda: Permission denied
所以fdisk 启动成功,打印了一些消息。然后它试图打开原始磁盘设备/dev/sda,并且是那个操作真正受到权限限制,所以fdisk只是抱怨它不能做任何事情并退出。
但在某些情况下,您可能希望限制某些用户对某些二进制文件的可执行性。当管理员或操作系统维护人员希望普通用户能够执行某些特权操作(例如安装某个特定用户在/etc/fstab 中的某些记录允许的分区)时,他们会设置一些特殊的强化二进制文件,例如@987654331 @ 或 sudo 具有 set-user-ID 权限:
$ ls -l /bin/mount /usr/bin/sudo
-rwsr-xr-x 1 root root 40152 May 27 02:31 /bin/mount
-rwsr-xr-x 1 root root 136808 Aug 17 16:20 /usr/bin/sudo
当执行这样的二进制文件时,内核给它的不是调用用户的用户 ID,而是在这种情况下,UID 0 (root)。因为普通用户不能以这种方式设置二进制文件(root 所有者和 set-UID 位设置),所以理论上可能值得将这些二进制文件的可执行性限制为某些特定组(但在上述情况下,它们是全局可执行的并检查权限自己调用用户。我真的不知道,如果不能以某种方式规避 set-UID 可执行文件的可执行性限制,以及这种方法是否真的被某人广泛使用)。
还有一点需要注意的是:如果您的系统上存在fdisk,它会安装到/usr/sbin 目录中,该目录可能在也可能不在普通用户的PATH 变量中,所以@987654336 @ 可能会或可能不会由普通用户通过在命令提示符下键入 fdisk 来执行,但这并不是真正的限制(可以简单地在命令行上指定可执行文件的完整路径)。