Journal Restreindre rsync avec git-shell

Posté par  . Licence CC By‑SA.
Étiquettes :
34
21
mai
2021

Un bon petit journal technique parce que j'ai pas trouvé comment faire ailleurs.

J'ai un serveur avec un compte git dont le shell de connexion est positionné sur git-shell. Ce dernier n'accepte que les commandes utilisées par git, afin de s'assurer que personne ne fasse des choses non autorisées.
Mon besoin vient de s'agrandir (Félicitations !), et j'ai besoin de faire de l'envoi de fichier à l'aide de rsync. git-shell mentionne la possibilité d'ajouter des commandes personnalisées. Parfait. De son côté, rsync fournit rrsync pour restreindre les répertoires visibles sur le serveur. Re-parfait.

Et là, c'est le drame. rrsync veut, et vérifie, qu'il est bien lancé par une session ssh. Je regarde le code, et j'en déduis qu'il se base sur la variable SSH_ORIGINAL_COMMAND. Donc c'est parti pour lui faire croire qu'il est en terrain connu.

Donc il faut créer un fichier ~/git-shell-commands/rsync exécutable, avec ça dedans :

#!/bin/sh

export SSH_ORIGINAL_COMMAND="rsync $@"
exec $HOME/bin/rrsync /srv/git/rsync_files/ $@

C'est pas long, et c'est fini. Bien sûr, il faut adapter. $HOME/bin/rrsync est l'emplacement (non standard) du script, et /srv/git/rsync_files/ correspond à mon serveur. Tous les appels à rsync fichiers git@monserveur:répertoire finiront dans /srv/git/rsync_files/répertoire/.

Évidemment, c'est le bricolage du jour. Si vous y voyez des grosses boulettes, n'hésitez pas à le signaler.

  • # intéressant…

    Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 23 mai 2021 à 02:49.

    …Je n'avais jamais vu quel usage on pouvait faire de la possibilité d'étendre git-shell ; alors merci pour le/la tuto/astuce.

    Mais, mais, c'est censé donné quoi si tu déposes directement des fichiers comme ça dans ton arborescence Git distant ? Et sinon, est-ce que Git-FS n'aurait pas été une option ?

    Si ce n'est pas dans l'arborescence d'un dépôt et pas de lien avec Git, pourquoi ne pas utiliser un compte idoine. (À voir si restricted shell convient à ton besoin.)

    Malgré mes réserves/interrogations, encore merci pour le bricolage du jour : c'est astucieux et ça m'a intrigué.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: intéressant…

      Posté par  . Évalué à 3.

      Mais, mais, c'est censé donné quoi si tu déposes directement des fichiers comme ça dans ton arborescence Git distant ?

      Et bien justement, rrsync fait une sorte de chroot. Donc c'est moi qui lui dit où vont se mettre les fichiers. Sur le serveur, il n'y a que des répertoires de git bare finissant en .git. Donc j'ai mis un répertoire à côté (nommé intelligemment rsync_files) dans lequel tout va se mettre, sans se mélanger.

      Et sinon, est-ce que Git-FS n'aurait pas été une option ?

      J'ai regardé Git-LFS, mais… voilà, j'ai plein de souci. Pas avec Git-LFS, non, mais avec le reste. Ce serveur est en SLES11, avec un openssl trop vieux, et le Git-LFS (du Gitea en conteneur LXC dans un Proxmox) est trop récent, le HTTPS passe pas. Oui, c'est bête. Oui, c'est sur la liste des choses à faire…

      Si ce n'est pas dans l'arborescence d'un dépôt et pas de lien avec Git, pourquoi ne pas utiliser un compte idoine.

      Si, justement, c'est en rapport. C'est parce que mon projet utilise yarn et sa gestion de paquets hors-ligne (les paquets en .tar.gz sont gardés quelque part pour pouvoir être utilisé par la plateforme de compilation qui n'a pas accès à Internet). Ça s'accumule avec le temps. Au début, je l'avais mis dans le dépôt git directement. Mais voilà, à force de faire les mises à jour, le dépôt git fait 400 Mo, pour 4 Mo de code utile. Donc j'ai cherché une autre solution, sachant que je n'ai pas besoin de l'historique.

      • [^] # Re: intéressant…

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Ah… il te faut un gestionnaire d'artéfacts, du genre Nessus quoi (mais je ne sais pas s'il existe d'équivalent léger…)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: intéressant…

          Posté par  . Évalué à 3.

          Je pense qe tu voulais parler de Nexus, le gestionnaire d'artefacts de Sonatype. Nessus est un outil d'évaluation des vulnérabilités.

          Comme alternative à Nexus, je connais au moins Artifactory de Gfrog, mais je ne pense pas que ce soit léger…

          • [^] # Re: intéressant…

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Tout à fait (le pire c'est que je fais souvent cette confusion et j'ai bien utilisé et administré les deux, ce qui excuse encore moins ma faute.) J'avais jeté un œil vite fait à Artifactory, et effectivement ça me semble assez léger par rapport au besoin que je comprends. Il doit bien exister quelqu'un qui a eu ce besoin quelque part.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

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