Pourquoi s'authentifier ?

D'où cela vient-il ? Est-ce le service gdm qui demande le mot de passe ou le binaire systemd ?

C'est le binaire systemctl. (Ou, plus précisément, la demande de "démarrage" va de systemctl à systemd au service PolicyKit, puis l'invite d'authentification revient en boucle au binaire "polkit-tty-agent" que systemctl génère).

Si vous avez déjà eu une demande de "mot de passe administrateur" en plein écran dans GNOME (comme lorsque vous essayez de changer la configuration du réseau ou d'exécuter pkexec ), c'est exactement la même chose.

Dans tous les cas, ce n'est pas gdm, car gdm n'a pas encore été lancé.

Je donne les permissions sudo alors pourquoi encore une fois ?

Ce n'est pas clair. Cette invite ne devrait en effet jamais être affichée lorsque systemctl est exécuté par root, car le code systemd ignore ces vérifications pour uid 0. (Du moins, je pense que c'est le cas. Je vais devoir revérifier.)

En général, PolicyKit est un système alternatif dont le but est de permettre l'utilisation de choses comme systemctl sans en utilisant explicitement sudo et en devenant root. Il est assez inhabituel que root reçoive une demande d'authentification de la part de polkit.

Suggestions :

• Exécuter journalctl -u polkit -n 100 et recherchez les messages qui mentionnent "gdm" ou "manage-units". Indiquent-ils "owned by unix-user:root" ou "unix-user:You" ?

• Essayez d'exécuter sudo pkexec . Cela devrait immédiatement donner un Shell sans aucune invite (alors que l'exécution de seulement pkexec devrait toujours demander l'authentification de l'administrateur). L'outil pkexec est comme "su mais avec plus de polkit".

• Réinstallez le paquet "polkit", pour vous assurer que les stratégies par défaut dans /usr/share/polkit-1 sont réinitialisées (au cas où elles auraient été corrompues). Je ne suis pas sûr que cela fonctionne, car systemd lui-même est censé ignorer complètement les vérifications de polkit pour root (c'est-à-dire que les politiques de polkit ne devraient pas être pertinentes), mais cela vaut la peine d'essayer.

• Vérifiez si le /run/systemd/private La prise existe. Lorsque systemctl est exécuté en tant que root, il utilisera cette socket pour faire une demande d'accès à la base de données. direct à systemd (au lieu de passer par D-Bus), et il devrait également contourner complètement tous les contrôles de polkit. sudo strace -e connect systemctl status foo pourrait être utile de vérifier.