SetUID 位在 Ubuntu 中不起作用?

SetUID 位在 Ubuntu 中不起作用?

我认为设置了 SetUID 位的可执行文件应该作为其所有者运行,但我无法真正重现它。我尝试了以下方法。

$ 猫准备.sh
cp /bin/bash 。
chown root.root bash
chmod 4770 bash # 已验证
$ sudo sh 准备.sh
$ ./bash
$ id -u
1000
$ 退出
$
$ 猫测试.c
#include<stdio.h>
#include<unistd.h>
int main(){
    printf("%d,%d\n", getuid(), geteuid());
    返回0;
}
$ gcc -o 测试 test.c
$ chmod 4770 测试 # 已验证
$ sudo chown root.root 测试
$ ./测试
1000,1000
$ # 为什么???

然而

$苏
# ./bash
#id-u
0
# 。/测试
0,0
# 出口
# 出口
$

注意:挂载点没有nosuid也没有noexec设置。
谁能解释为什么它无法在 Ubuntu 16.04 LTS 上运行?

答案1

对于编译后的可执行文件,来自man 2 chown

When the owner or group  of  an  executable  file  are  changed  by  an
unprivileged user the S_ISUID and S_ISGID mode bits are cleared.  POSIX
does not specify whether this also should happen  when  root  does  the
chown();  the Linux behavior depends on the kernel version.

颠倒chownchmod顺序对我有用:

$ sudo chmod 4770 foo
$ sudo chown root:root foo
$ stat foo
  File: 'foo'
  Size: 8712        Blocks: 24         IO Block: 4096   regular file
Device: 801h/2049d  Inode: 967977      Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-04-18 15:15:15.074425000 +0900
Modify: 2017-04-18 15:15:15.074425000 +0900
Change: 2017-04-18 15:15:33.683725000 +0900
 Birth: -
$ sudo chmod 4777 foo
$ ./foo
1000,0

答案2

在第一种情况下,Bash 不喜欢作为 setuid 运行。

如果 Bash 启动时有效用户(组)id 不等于真实用户(组)id,...,并且有效用户 id 设置为真实用户 id。

看:Bash 的启动文件手册, 还setuid 位似乎对 bash 没有影响

chmod在第二种情况下,重要的是和的顺序chown,正如 muru 已经回答了。更改所有者会重置 setuid 位。

答案3

也可能是包含测试可执行文件的文件系统是用nosuid选项;我听说较新的发行版默认会执行此操作,并且也 /tmp有很好的论据将其应用到。导致内核忽略 setuid 和 setgid 位/homenosuid全部文件系统内的可执行文件。 (当你做一个不相关的事情时发生目录setgid 不受影响。)

相关内容