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 不受影響。

相關內容