SetUID pouco não funciona no Ubuntu?

Question

Suponho que um arquivo executável com set de bits SetUID esteja sendo executado como proprietário, mas não consigo reproduzi-lo. Eu tentei o seguinte.

$ cat prepare.sh
cp /bin/bash .
chown root.root bash
chmod 4770 bash # Verified
$ sudo sh prepare.sh
$ ./bash
$ id -u
1000
$ exit
$

$ cat test.c
#include<stdio.h>
#include<unistd.h>
int main(){
    printf("%d,%d\n", getuid(), geteuid());
    return 0;
}
$ gcc -o test test.c
$ chmod 4770 test # Verified
$ sudo chown root.root test
$ ./test
1000,1000
$ # Why???

No entanto

$ su
# ./bash
# id -u
0
# ./test
0,0
# exit
# exit
$

Nota: O ponto de montagem não possui nosuid nem noexec conjunto.
Alguém pode explicar por que está falhando em trabalhar no Ubuntu 16.04 LTS?

    

Answer 1

Para o executável compilado, de 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.

Reverter a ordem chown e chmod funciona para mim:

$ 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

    

Answer 2

No seu primeiro caso, é o Bash que não gosta de ser executado como setuid.

If Bash is started with the effective user (group) id not equal to the real user (group) id,..., and the effective user id is set to the real user id.

Veja: Manual do Bash em arquivos de inicialização , também O bit setuid parece não ter efeito no bash .

No segundo caso, é a ordem de chmod e chown que importa, já que a muru respondeu . Alterar o proprietário redefine o bit setuid.

    

Answer 3

Também pode ser que o sistema de arquivos que contém o executável de teste tenha sido montado com o nosuid opção ; Ouvi dizer que as distribuições mais recentes farão isso por padrão para /tmp , e há bons argumentos para aplicá-lo a /home também. nosuid faz com que o kernel ignore os bits setuid e setgid nos executáveis todos dentro do sistema de arquivos. (A coisa não relacionada que acontece quando você faz um diretório setgid não é afetado.)