Il bit SetUID non funziona in Ubuntu?

8

Suppongo che un file eseguibile con il set di bit SetUID dovrebbe essere in esecuzione come proprietario ma non riesco davvero a riprodurlo. Ho provato quanto segue.

$ cat prepar.sh
cp / bin / bash.
chown root.root bash
chmod 4770 bash # Verificato
$ sudo sh prepar.sh
$ ./bash
$ id -u
1000
$ uscita
$

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

però

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

Nota: il punto di montaggio non ha nosuidné noexecimpostato.
Qualcuno può spiegare perché non funziona su Ubuntu 16.04 LTS?

setuid

— iBug
fonte

3

Possibile duplicato di Consenti setuid su script shell

— Kusalananda

3

@Kusalananda non è una sceneggiatura.

— enzotib,

4

La sceneggiatura è un po 'confusa, ma è solo un'aringa rossa. Suppongo sia lì per salvare due usi di sudo? C'è un bug o un refuso in esso, tuttavia, chmodmanca un nome di file.

— ilkkachu,

15

Per l'eseguibile compilato, da 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.

Invertire l' ordine chowne chmodfunziona per me:

$ 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

— Muru
fonte

15

Nel tuo primo caso, è Bash a cui non piace essere eseguito come setuid.

Se Bash viene avviato con l'ID utente (gruppo) effettivo non uguale all'id utente (gruppo) reale, ... e l'id utente effettivo viene impostato sull'ID utente reale.

Vedi: Il manuale di Bash sui file di avvio , anche Setuid bit sembra non avere alcun effetto su bash .

Nel secondo caso, è l'ordine di chmode chownciò che conta, come ha già risposto Muru . La modifica del proprietario reimposta il bit setuid.

— ilkkachu
fonte

Oh, non ho notato che l'OP stava usando la configurazione dello script un setuid bash.

— muru,

5

Potrebbe anche essere che il filesystem contenente l'eseguibile del test sia stato montato con l' nosuidopzione ; Ho sentito che le nuove distribuzioni lo faranno di default per /tmp, e ci sono buoni argomenti anche per applicarlo /home. nosuidfa sì che il kernel ignori i bit setuid e setgid su tutti gli eseguibili all'interno del filesystem. (La cosa non correlata che si verifica quando si crea una directory setgid non è interessata.)

— Zwol
fonte