sudo et root
Le compte root, su et sudo, le fichier sudoers édité avec visudo, les groupes sudo et wheel, la forme d'une règle (qui, où, en tant que qui, quoi), le moindre privilège et la trace laissée par sudo.
- 28 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
root : de quoi s'agit-il ?
Voir la réponse
Compte d'administration de UID 0, auquel le noyau n'applique pas les contrôles d'accès aux fichiers.
Une faute de frappe sous ce compte (rm -rf mal placé) n'est arrêtée par rien. D'où l'usage de ne s'élever qu'à la demande, commande par commande.
Dans cet extrait de sudoers, que peut faire tom avec sudo, en supposant qu'il n'appartient à aucun groupe cité ?
```text
Defaults env_reset
root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
tom ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
%ops ALL=(root) /usr/bin/systemctl status *`- Relancer nginx en root sans mot de passe, et rien d'autre
- Tout faire en root, sans mot de passe
- Relancer nginx en root, mais en tapant son mot de passe
- Relancer et arrêter n'importe quel service sans mot de passe
Voir la réponse
Relancer nginx en root sans mot de passe, et rien d'autre
NOPASSWD: supprime la demande de mot de passe pour la seule commande listée, avec ses arguments exacts. sudo systemctl stop nginx serait refusé. C'est le moindre privilège appliqué.
Le compte … a pour UID … : c'est ce numéro, et non son nom, qui lui donne ses pouvoirs.
Voir la réponse
Le compte root a pour UID 0 : c'est ce numéro, et non son nom, qui lui donne ses pouvoirs.
Un autre compte créé avec l'UID 0 aurait les mêmes pouvoirs que root, ce qui est une porte dérobée classique à repérer dans /etc/passwd.
su : de quoi s'agit-il ?
Voir la réponse
Commande qui ouvre un shell sous un autre compte, après avoir demandé le mot de passe de ce compte.
Avec le tiret, su - charge aussi l'environnement du compte visé. Son défaut : le mot de passe de root doit être connu de chaque administrateur.
Après un
sudo git pull, Léa ne peut plus modifier son propre dépôt : « Permission denied ». Quelle est la cause et la solution ?- Git a retiré le droit d'écriture après le pull ; un chmod -R 777 sur le dépôt règle tout
- Des fichiers sont à root : sudo chown -R lea: sur le dépôt, puis plus de sudo pour git
- Léa a quitté le groupe sudo ; usermod -aG sudo lea la rétablit
- Le dépôt est verrouillé tant que le pull n'est pas terminé ; il suffit d'attendre
Voir la réponse
Des fichiers sont à root : sudo chown -R lea: sur le dépôt, puis plus de sudo pour git
sudo lance git sous root : les fichiers créés ou modifiés lui appartiennent, et Léa, ni propriétaire ni dans le groupe, n'a plus le droit d'écrire. Le bon réflexe : sudo seulement pour ce qui l'exige.