¿El bit SetUID no funciona en Ubuntu?

8

Supongo que un archivo ejecutable con el conjunto de bits SetUID debería ejecutarse como su propietario, pero realmente no puedo reproducirlo. Intenté lo siguiente.

$ cat prepare.sh
cp / bin / bash.
chown root.root bash
chmod 4770 bash # verificado
$ sudo sh prepare.sh
$ ./bash
$ id -u
1000
$ salida
PS

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

sin embargo

$ su
# ./bash
# id -u
0 0
# ./prueba
0,0
# salida
# salida
PS

Nota: El punto de montaje no tiene nosuidni noexecestablecido.
¿Alguien puede explicar por qué no funciona en Ubuntu 16.04 LTS?

setuid

— iBug
fuente

3

Posible duplicado de Permitir setuid en scripts de shell

— Kusalananda

3

@Kusalananda no es un guión.

— enzotib

44

El guión es un poco confuso, pero es solo una pista falsa. Supongo que está ahí para guardar dos usos de sudo? Sin embargo, hay un error o un error tipográfico en el que chmodfalta un nombre de archivo.

— ilkkachu

15

Para el ejecutable 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.

Invertir el orden chowny chmodfunciona para mí:

$ 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
fuente

15

En su primer caso, es Bash a quien no le gusta que se ejecute como setuid.

Si Bash se inicia con la identificación efectiva del usuario (grupo) no igual a la identificación real del usuario (grupo), ..., y la identificación efectiva del usuario se establece en la identificación real del usuario.

Ver: Manual de Bash sobre archivos de inicio , también el bit Setuid parece no tener efecto en bash .

En el segundo caso, es el orden de chmody lo chownque importa, como muru ya respondió . Cambiar el propietario restablece el bit setuid.

— ilkkachu
fuente

Oh, no me di cuenta de que el OP estaba usando la configuración del script en un setuid bash.

— muru

5

También podría ser que el sistema de archivos que contiene el ejecutable de prueba se haya montado con la nosuidopción ; He escuchado que las distribuciones más nuevas lo harán de forma predeterminada para /tmp, y también hay buenos argumentos para aplicarlo /home. nosuidhace que el núcleo ignore los bits setuid y setgid en todos los ejecutables dentro del sistema de archivos. (Lo que no está relacionado que sucede cuando crea un directorio setgid no se ve afectado).

— zwol
fuente