为什么 setuid 对可执行文件不起作用？

Question

我知道在脚本上启用 setuid 存在安全问题，因此默认情况下处于非活动状态，但希望它适用于可执行文件。我创建了一个可执行文件，它按照这篇文章中描述的说明显示 uid 作为输出：Allow setuid on shell scripts

但它在运行之前和之后返回相同的 uid (1000) sudo chmod +s ./setuid-test。我认为这意味着 setuid 对我的可执行文件没有任何影响，为什么以及如何解决？

源代码：

#include <stdio.h>
#include <unistd.h>
int main(int argc, char** argv) {
    printf("%d", geteuid());
    return 0;
}

构建和运行

$ gcc -o setuid-test setuid-test.c
$ ./setuid-test
1000
$ sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
$ ./setuid-test
1000

运行时ls -la，这就是我得到的：

me@me:~$ ls -la setuid-test
-rwsrwsr-x 1 nobody me 8572 Aug 19 16:39 setuid-test

Answer 1

大多数为 Unix/Linux 设计的文件系统都可以用一个nosuid属性挂载，这将防止位于这些文件系统上的 setuid 或 setgid 二进制文件改变进程的有效 uid 或 gid。它通常用于挂载“不受信任”的文件系统，即那些受非管理员控制的文件系统。

在您的情况下，您使用的文件系统是 ecryptfs 类型，根据askubuntu: Error when running binary with root setuid under encrypted home directory自动强制执行 nosuid（和 nodev），从几年前的版本开始。

以下是更改原因的说明，来自https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3409：

Vincent Danen 2012-07-20 11:25:56 EDT
据报道，私有 ecryptfs 挂载助手 (/sbin/mount.ecryptfs_private)，即 setuid-root，可以允许非特权本地用户挂载用户控制的 ecryptfs 共享在本地系统上。由于 ecryptfs 帮助程序不使用“nosuid”和“nodev”标志挂载文件系统，因此用户可能挂载包含 setuid-root 二进制文件和/或设备文件的文件系统，这可能会导致其权限升级。如果用户可以物理访问系统，这可以通过 USB 设备完成。
...
强制 MS_NOSUID 和 MS_NODEV 挂载标志已添加到版本 99。

Answer 2

可执行文件上的 SetUID 位允许在文件所有者（而非超级用户）处运行可执行文件。为了能够以 root 身份运行可执行文件，请执行：

sudo chown 0:0 ./setuid-test