Le bit setuid semble n'avoir aucun effet sur bash

J'expérimentais un peu et j'ai remarqué quelque chose d'étrange: placer le bit setuid sur une copie de bash située à /usr/bin/bash-testsemblait n'avoir aucun effet. Lorsque j'ai exécuté une instance de bash-test, mon répertoire personnel n'était pas défini sur /rootet lorsque j'ai exécuté la whoamicommande à partir de bash-test, mon nom d'utilisateur n'était pas signalé comme étant root, ce qui suggère qu'il bash-testne s'exécutait pas en tant que root. Cependant, si j'ai activé le bit setuid whoami, j'ai été signalé comme étant root dans n'importe quel shell, comme prévu.

J'ai également essayé d'activer le bit setuid et j'ai /usr/bin/bashobservé le même comportement.

Pourquoi bash ne s'exécute-t-il pas en tant que root lorsque j'y mets le bit setuid? Selinux pourrait-il avoir quelque chose à voir avec cela?

L'explication est assez ennuyeuse: bash lui-même en est la raison. straceest notre ami (doit être la racine SUID elle-même pour que cela fonctionne):

getuid()                                = 1000
getgid()                                = 1001
geteuid()                               = 0
getegid()                               = 1001
setuid(1000)                            = 0
setgid(1001)                            = 0

bash détecte qu'il a démarré la racine SUID (UID! = EUID) et utilise sa puissance racine pour rejeter cette puissance, réinitialisant EUID à UID. Et plus tard, même FSUID, juste pour être sûr ...:

getuid()                                = 1000
setfsuid(1000)                          = 1000
getgid()                                = 1001
setfsgid(1001)                          = 1001

Au final: aucune chance. Vous devez démarrer bash avec la racine UID (c'est-à-dire sudo).

Modifier 1

La page de manuel dit ceci:

Si le shell est démarré avec l'ID utilisateur (groupe) effectif différent de l'ID utilisateur réel (groupe) et que l'option -p n'est pas fournie, aucun fichier de démarrage n'est lu, les fonctions shell ne sont pas héritées de l'environnement, le SHELLOPTS , Les variables BASHOPTS, CDPATH et GLOBIGNORE, si elles apparaissent dans l'environnement, sont ignorées et l'ID utilisateur effectif est défini sur l'ID utilisateur réel. Si l'option -p est fournie lors de l'appel, le comportement de démarrage est le même, mais l'ID utilisateur effectif n'est pas réinitialisé.

Mais cela ne fonctionne pas pour moi. -pn'est même pas mentionné parmi les options de démarrage. J'ai aussi essayé --posix; n'a pas fonctionné non plus.

Dans tous les cas, un programme racine SUID ne s'exécute pas avec l'environnement root ( $HOME, configuration pour le shell, peu importe), il s'exécute avec les pouvoirs root (c'est-à-dire qu'il peut supprimer n'importe quel fichier, modifier toutes les autorisations, etc.).