Forum Programmation.autre Utiliser git+ssh et sudo en utilisant sa clé à soi !

Posté par  . Licence CC By‑SA.
Étiquettes :
2
22
jan.
2013

Avec mon collègue nous avons des environnements de test que nous utilisons tour à tour. Cet environnement est éventuellement chez un utilisateur demo (par exemple) avec un groupe demo auquel nous appartenons tous les deux.

Le problème est que pour faire les mises à jour avec git, il faut posséder le dépôt (le dossier .git) car git est un peu exclusif sur les permissions de certains fichiers là dedans (lors des push et pull en tout cas). Donc si je devais faire une mise à jour produit il me fallait d'abord lancer un violent sudo chown moi: -R .. Lourd !

Heureusement après une recherche de git ssh-agent sudo sur le web, je suis tombé sur http://mybrainhurts.com/blog/2012/05/git-sudo-local-ssh-keys.html et j'ai pu m'en inspirer !

Donc si je veux pouvoir git pull avec l'utilisateur demo je peux faire ça :

$ chown :demo -R ${SSH_AUTH_SOCK%/*}
$ chmod g+rwX -R ${SSH_AUTH_SOCK%/*}
$ sudo -E -u demo git pull

(ou bien sur faire toute une session avec sudo -E -u demo -s)
À noter que ceci fonctionne si on utilise ssh-agent et, pour les serveurs distant, si l'on fait bien suivre les clés avec ssh (option -A ou ForwardAgent).

Explication :

SSH_AUTH_SOCK est la variable qui contient le socket de communication avec ssh-agent. ${SSH_AUTH_SOCK%/*} contient donc le dossier parent (merci http://www.tldp.org/LDP/abs/html/string-manipulation.html). Le chown et chmod donnent donc accès au ssh-agent aux utilisateurs du groupe demo.

L'option -E de sudo conserve les variables d'environnement (dont le SSH_AUTH_SOCK).

La commande git va donc utiliser le ssh-agent de votre utilisateur pour se connecter au dépôt distant, le tour est joué !

Bien sur je met le

$ chown :demo -R ${SSH_AUTH_SOCK%/*}
$ chmod g+rwX -R ${SSH_AUTH_SOCK%/*}

dans un fichier texte et je n'est plus qu'a utiliser source sur ce fichier pour l'utiliser.

[EDIT] voir la solution de git --shared ci-dessous par sufflop, c'est bien mieux !

  • # ACL

    Posté par  (site web personnel) . Évalué à 3.

    Pour éviter les modifications des droits, j'utilise maintenant les ACLs.

    Le principe, le dossier m'appartient mais je fait en plus :

    setfacl -R -m u:demo:rwX dossier
    setfacl -R -m d:u:demo:rwX dossier
    
    

    La seconde commande permet de définir les droits par défaut sur dossier et ainsi tous les fichiers obtiennent possèdent automatiquement des autorisations pour demo.

    Grace aux ACL, il est possible de dir

    setfacl -R -m u:demo:rwX dossier
    setfacl -R -m d:u:demo:rwX dossier
    setfacl -R -m u:user1:rwX dossier
    setfacl -R -m d:u:user1:rwX dossier
    setfacl -R -m u:user2:rwX dossier
    setfacl -R -m d:u:user2:rwX dossier
    
    

    Pour que demo, user1, et user2 soit content.

    Le FS doit être monté avec les acl activé bien sur.

  • # Dépôt shared

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 24 janvier 2013 à 10:37.

    Normalement si tu initialises ton dépôt avec l'option shared=group ( git init --bare shared=group myproject.git ) en tant que demo, git créera les fichiers avec les bons droits pour que tout le groupe demo puisse push.

    C'est aussi rattrapable après coup en ajoutant l'option dans le fichier config et en faisant un chmod de ratrapage qui va bien.

    • [^] # Re: Dépôt shared

      Posté par  . Évalué à 1.

      C'est en effet plus simple ! Merci, je vais essayer.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.