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

我知道在脚本上启用setuid会带来安全问题，因此默认情况下处于禁用状态，但是希望它对可执行文件有效。我创建了一个可执行文件，该文件按照本文中所述的说明将uid显示为输出：在shell脚本上允许setuid

但是它在运行之前和之后都返回相同的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

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

在您的情况下，您正在使用的文件系统是ecryptfs类型，根据askubuntu的说法：在加密主目录下使用root setuid运行二进制文件时出错，从几年前的版本开始自动执行nosuid（和nodev）。

这是更改原因的描述，网址为https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3409：

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

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

sudo chown 0:0 ./setuid-test