sudo · sudo-rs

sudo « must be owned by uid 0 and have the setuid bit set » alors que le fichier est root et setuid

Publié le 2026-11-06 · HardStacked · 10 min

Tu tapes sudo et tu reçois sudo: sudo must be owned by uid 0 and have the setuid bit set (Ubuntu 26.04, qui livre sudo-rs) ou sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set (sudo classique, qui en français donne sudo: /usr/bin/sudo doit être la propriété du uid 0 et avoir le bit setuid mis). Tu fais ls -l, et le fichier est exactement ce que le message réclame. Dans une question sur Server Fault, la personne qui pose la question l'écrit mieux que nous : "I've confirmed that both file's owner is root, and I believe the setuid has been set." Puis : "What did I miss here?" (question 1154208, RHEL 8.9, Ansible Tower, 1 351 vues au 2026-11-06). La réponse habituelle, c'est chown root et chmod 4755. Si le fichier est déjà root et setuid, ça ne change rien.

Le message accuse le fichier, mais il ne sait qu'une chose : sudo n'a pas démarré en root. Trois lignes, lancées sans root, disent pourquoi : le fichier lui-même (le vrai, parce que sur Ubuntu 26.04 /usr/bin/sudo est un lien), le montage qui le porte (nosuid), et l'identité du processus qui le lance (Uid 65534, un user namespace). Sur Ubuntu 26.04, sudo-rs ne regarde même pas le fichier : il affiche ce message dès qu'il démarre sans root, quelle qu'en soit la raison, sauf « no new privileges ». Sur un montage nosuid, l'ancien sudo disait nosuid ; sudo-rs accuse le fichier.

Mesuré sur une machine virtuelle Ubuntu 26.04.1 LTS neuve (arm64, image cloud officielle), sudo-rs 0.2.13-0ubuntu1.2, sudo 1.9.17p2-1ubuntu3.2 (installé à côté sous le nom sudo.ws), systemd 259.5, le 2026-11-06. L'utilisateur est un admin ordinaire : groupe sudo, avec un mot de passe.

01. Ce que le message affirme, et ce que sudo sait vraiment

D'abord, quel sudo as-tu, et c'est quoi vraiment ?

Premier piège : sur 26.04, le ls -l simple montre lrwxrwxrwx, aucun s nulle part, et c'est normal. Il ne dit rien sur le bit. ls -lL suit le lien et montre la cible.

Le code dit ce que sudo sait. Dans sudo.ws (src/sudo.c), quand l'UID effectif n'est pas 0, il teste trois choses dans cet ordre. Si le flag no_new_privs est posé, il affiche le message « no new privileges ». Sinon il fait un stat() de son propre binaire : propriétaire différent de 0, ou pas de bit setuid, et c'est notre message. Si le fichier est correct, il affiche effective uid is not 0, is … on a file system with the 'nosuid' option set or an NFS file system without root privileges?. Donc le sudo classique regarde le fichier, et le chemin dans le message est celui qu'il a vérifié. Dans sudo-rs 0.2.13 (src/sudo/mod.rs, self_check), no_new_privs a son propre message, et tout autre UID effectif non nul donne notre message, sans aucun stat(). C'est pour ça que la forme sudo-rs n'a pas de chemin : sudo must be owned… c'est sudo-rs, /usr/bin/sudo must be owned… c'est le classique.

02. Trois lignes qui disent ce qui a vraiment bloqué sudo

Rien ici ne demande root. Tout ce que les démos créent vit dans /opt/demo-sudo et /opt/demo-ns, des copies de sudo : le vrai sudo n'est jamais touché, et tout est retiré à la fin. Les démos, elles, demandent un sudo qui marche (une machine saine, ou une VM). Le diagnostic, non.

Voilà une machine saine, ligne par ligne. Le fichier est root root avec un s. Les options de montage n'ont pas nosuid. Le processus est Uid 1000 et NoNewPrivs 0. En panne, une de ces lignes change : pas de s, ou un propriétaire qui n'est pas root (le bit est vraiment parti) ; nosuid dans les options ; Uid 65534 ; ou NoNewPrivs 1.

Le dernier donne un autre message, donc ce n'est pas notre cas, mais le voici :

Si c'est le tien, tu es dans un conteneur ou un service qui pose ce flag.

03. Le bit est vraiment parti : chown, chmod -R, et retrouver root

Une question Super User (1816624, Fedora 37, 22 205 vues au 2026-11-06, aucune réponse acceptée) est le cas réel : la personne avait lancé sudo chmod -R 755 /usr/bin/. Là, le bit est vraiment parti. On copie sudo dans /opt/demo-sudo avec le bon mode comme témoin, puis on le chown à nous-mêmes :

On n'a jamais lancé chmod. Le chown a effacé le s tout seul, c'est pourquoi un chown -R sur /usr casse sudo sans un seul chmod.

Deux choses mesurées sur une 2ᵉ VM 26.04, hors capture. sudo chmod -R 755 /usr/bin ne casse PAS sudo-rs sur 26.04 : son binaire vit dans /usr/lib/cargo/bin et chmod -R ne suit pas les liens. Mais su, passwd, mount et sudo.ws perdent leur bit en silence. Et dpkg --verify ne dit rien : 0 ligne, et dpkg --verify passwd retourne 0 alors que passwd est -rwxr-xr-x. man dpkg (1.23.7) est clair : « Currently the only functional check performed is an md5sum verification of the file contents against the stored value in the files database. » La réponse Super User utilise rpm -Va sur Fedora, qui voit propriétaires et modes. C'est ce que dit la réponse, pas une mesure de notre part.

Maintenant, comment réparer quand c'est sudo qui est cassé ? La réponse la plus votée de cette question Super User (score 6) commence par devenir root autrement : machinectl shell, systemd-run --shell ou run0. Sur Ubuntu 26.04, run0 est là, et il passe par polkit, pas par le binaire sudo. Les règles polkit livrées déclarent unix-group:sudo (et admin) comme administrateurs, donc run0 demande le mot de passe d'un membre du groupe sudo :

À Password:, tu tapes TON mot de passe. La copie est root et rws de nouveau. On l'a aussi testé pour de vrai, hors capture, sur une VM où sudo-rs était cassé par chmod 755 : un utilisateur hors du groupe sudo a lancé run0, polkit a proposé de s'authentifier comme l'admin (« Authenticating as: <admin> »), et chmod 4755 a réparé sudo. Il faut un terminal (sans terminal, run0 dit « requires interactive authentication ») et le mot de passe d'un membre du groupe sudo. Chez toi, la vraie commande est run0 sh -c 'chown root:root /usr/lib/cargo/bin/sudo && chmod 4755 /usr/lib/cargo/bin/sudo', ou le chemin de ta propre ligne readlink -f. Pas d'admin avec mot de passe : le mode recovery de GRUB devrait marcher, on ne l'a pas mesuré.

04. Le fichier va bien, tu es « nobody »

C'est la forme de la question Server Fault. Dans un user namespace qui ne mappe ni toi ni root, ton UID devient 65534 et root n'existe pas pour le processus. unshare -U construit exactement ça :

Même fichier, même rws, mais le propriétaire est maintenant nobody nogroup. Avec le sudo classique, tu as en plus la ligne signature du cas :

/etc/sudo.conf is owned by uid 65534 au-dessus du message, c'est exactement ce que la personne de Server Fault a collé. Dans cette question, sa propre réponse acceptée dit que Tower 3.8 isole l'exécution des tâches avec Bubblewrap, et le correctif a été de ne plus passer par sudo dans ces tâches (become: false). Bubblewrap exécute la tâche dans un user namespace : c'est ce que fait Bubblewrap, mais on ne l'a pas mesuré sur Tower. Des fils des forums LXC et Ansible portent le même message ; on n'a pas reproduit ces montages. Le correctif n'est pas de lancer sudo de là : lance-le depuis l'hôte, ou donne au conteneur ou à la tâche les droits qu'il faut.

05. Le fichier va bien, le montage dit nosuid

Même fichier, même rws, et le système de fichiers ignore le bit. On monte un petit tmpfs avec nosuid et on y met les deux sudo :

Les deux fichiers sont root et rws. Même cause, deux messages : sudo-rs accuse le fichier, qui est correct, et sudo.ws dit la vérité.

Ce n'est pas un cas exotique. /tmp est nosuid par défaut sur l'image cloud 26.04 qu'on a utilisée :

Un sudo extrait ou compilé dans /tmp tombe ici. Autres versions réelles : un /usr ou un /home monté avec nosuid, un partage NFS. On a aussi mesuré sur ZFS (hors capture, pool de test) : un dataset avec setuid=off apparaît nosuid dans findmnt et donne notre message, et zfs inherit setuid <dataset> le remet à on et sudo remarche. Une question Ask Ubuntu de septembre 2026 (« sudo must be owned by uid 0 and have the setuid bit set on ZFS installs », message sans chemin, donc sudo-rs) ressemble à ce cas. C'est une ressemblance : la question ne donne ni findmnt ni zfs get, on ne peut pas dire que c'est la cause.

La réparation sur notre tmpfs :

06. Nettoyage

Non mesuré : macOS (où le même message existe), Fedora, WSL, Tower lui-même. Ubuntu 25.10 livre un sudo-rs plus ancien (0.2.8 selon Launchpad) : pas mesuré. On a vérifié Debian 13 (sudo 1.9.16p2) : même message et même ligne /etc/sudo.conf … 65534 sous unshare -U.