我认为设置了 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.
颠倒chown
和chmod
顺序对我有用:
$ 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 位/home
nosuid
全部文件系统内的可执行文件。 (当你做一个不相关的事情时发生目录setgid 不受影响。)