Lancer des commandes avec les droits d’un autre utilisateur

Cet article a été publié il y a 7 ans 3 mois 28 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

J’ai eu cette problématique récemment où l’on me demande des comptes SSH nominatifs qui doivent tous pouvoir lacner des commandes git sur le dossier d’un autre utilisateur. Il y a plusieurs façons de faire, voyons donc voir comment s’en sortir.

Pour simplifier par la suite, admettons qu’on aie deux comptes nominatifs, Juan et Sanchez, et que le compte qui doit effectuer les commandes s’appelle Ramirez. Je vous laisse chercher la référence, je voulais juste laisser Alice et Bob vaquer à leurs occupations.

Première possibilité : su

su est la commande qui permet de changer d’utilisateur. Pour ça, il faut par conséquent connaitre le mot de passe de l’utilisateur qu’on veut endosser. Rien de transcendant là-dedans, mais il y a plusieurs inconvénients. Parmi eux, tous les utilisateurs partagent donc le même mot de passe, puisque c’est celui du compte qui doit effectuer les commandes. Moralité, si l’on veut retirer le droit d’exécuter des commandes à une des personnes sans supprimer son compte, c’est la loose, il faut changer le mot de passe du compte « exécutif ». Dans notre exemple, Juan et Sanchez lancent la commande su Ramirez, puis saisissent le mot de passe de Ramirez. Si l’ont veut retirer l’accès à Sanchez, il faut changer le mot de passe de Ramirez et ne le transmettre qu’à Juan. Ajoutez à ça que Ramirez peut également être un vrai compte et pas juste un compte que j’ai créé côté serveur, et c’est la misère.

Bref, vous l’aurez compris, c’est une catastrophe en termes de gestion des accès, et pas génial non plus en termes de sécurité (on a alors le droit de faire ce qu’on veut avec le compte Ramirez, ce qui n’est pas ce qu’on cherche).

Jouons avec les groupes

Une des choses que j’ai pu voir sur certains serveurs. Juan, Sanchez, et Ramirez sont dans un bateau font partie du même groupe d’utilistateurs (espagnol), et les droits d’écriture pour le groupe sont présents sur les parties de l’arborescence qui sont à modifier par les trois énergumènes. C’est relativement simple, assez visuel au sein d’un ls -l, et le noyau tient compte des droits existants pour la création d’éventuels fichiers/dossiers.

Mais là encore, c’est pas super propre, si les utilisateurs ne changent plus d’identité, ils ont toujours tous les droits sur la fameuse arborescence qui ne leur appartient pas. Ce n’est toujours pas ce qu’on cherche.

sudo, la solution flexible

J’ai déjà introduit sudo pour son installation sous Debian, et vaguement évoqué les possibilités. Ici, c’est un cas très concrêt qui s’offre à nous. Par rapport aux options précédentes, sudo a toutes les qualités dont on a besoin. Sa raison d’être est justement de pouvoir lancer une commande en « empruntant » l’identité d’un autre utilisateur uniquement pour cette commande. L’usage le plus courant des distributions linux est de donner des droits administrateurs à un utilisateur pour lui permettre d’installer des logiciels.

Et donc peu de personnes savent qu’on peut utiliser sudo pour endosser une autre identité que celle de l’administrateur. Mieux encore, on peut demander à celui-ci de restreindre les commandes qu’on peut exécuter quand on veut changer de nom (et donc de droits). Et cerise sur le gateau, on n’a pas besoin de connaître le mot de passe de l’utilisateur final (Ramirez), puisque sudo ne demandera que le mot de passe de l’utilisateur qui demandera à changer de nom le temps d’une commande.

Pour la configuration, c’est super simple, on se rend dans le dossier /etc/sudoers.d,  et on crée un fichier nommé juan, dans lequel on inscrit la ligne suivante :

C’est aussi simple que ça. Avec ça, Juan pourra exécuter toutes les commandes git sous l’identité de ramirez, il suffira d’appeler git de la manière suivante :

Et si Sanchez veut aussi être de la fête, il suffit d’ajouter son fichier dans le dossier en remplaçant juan. La suppression est tout aussi simple.

Accessoirement, on peut aussi reprendre notre groupe (remember espagnol), et remplacer l’utilisateur par  %espagnol dans le fichier de configuration, et tous les membres du groupe pourront emprunter l’identité de ramirez, et toujours uniquement pour des commandes git.

Pourquoi pas les ACL ?

Déjà parce que je les maitrise mal, et surtout, c’est très peu visible des outils habituels de gestion des droits d’accès. Il est donc facile de les oublier, et quand on est plusieurs à administrer le serveur, même la meilleure documentation ne sera d’aucun secours, puisque vous avez une chance sur deux qu’elle ne soit pas lue.

C’est une solution intéressante, puissante, mais difficile à maitriser, et comme j’ai dit, comme ce n’est pas un outil courant, vous avez de grandes chances que vos collègues ne soient pas aware le jour où vous devez modifier quelque chose dans le setup.

D’autres pistes ?

Je suis curieux de savoir comment vous auriez procédé. Comme trop souvent je n’ai trouvé pratiquement que des ressources anglaises à ce sujet, et donc ça serait vraiment intéressant de voir les solutions partagées dans la langue de Molière.