SetUID位在Ubuntu中不起作用？

8

我以为设置了SetUID位的可执行文件应以其所有者身份运行，但我无法真正复制它。我尝试了以下方法。

$ cat prepare.sh
cp / bin / bash。
chown root.root bash
chmod 4770 bash＃已验证
$ sudo sh prepare.sh
$ ./bash
$ id -u
1000
$出口
$

$ cat test.c
#include <stdio.h>
#include <unistd.h>
int main（）{
    printf（“％d，％d \ n”，getuid（），geteuid（））;
    返回0;
}
$ gcc -o test test.c
$ chmod 4770测试＃验证
$ sudo chown root.root测试
$ ./测试
1000,1000
$＃为什么？？？

然而

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

注意：安装点没有nosuid，也没有noexec设置。
谁能解释为什么它无法在Ubuntu 16.04 LTS上运行？

setuid

— iBug
source

3

壳脚本

— Kusalananda

3

@Kusalananda不是脚本。

— enzotib

4

该脚本有点混乱，但这只是一个红色鲱鱼。我想它在那里可以保存两种用法sudo？不过，其中存在错误或错字，chmod缺少文件名。

— ilkkachu

15

对于编译的可执行文件，来自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

— uru
source

15

在第一种情况下，Bash不喜欢以setuid的身份运行。

如果Bash在有效用户（组）ID与真实用户（组）ID不相等的情况下启动，...，并且有效用户ID设置为真实用户ID。

请参阅：Bash关于启动文件的手册，Setuid位似乎对bash也没有影响。

在第二种情况下，这是顺序的，chmod而chown这很重要，因为大师已经回答了。更改所有者将重置setuid位。

— 伊尔卡楚
source

哦，我没注意到OP正在使用脚本设置setuid bash。

— muru

5

也可能是包含测试可执行文件的文件系统是通过nosuid选项挂载的; 我听说过，默认情况下，较新的发行版将执行此操作/tmp，并且有很好的理由将其应用于/home。 nosuid使内核忽略文件系统中所有可执行文件上的setuid和setgid位。（创建目录 setgid 时发生的无关事件不受影响。）

— 兹沃尔
source