This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

Modèle de communication réseau
Précédent  Chapitre 3. Sujets avancés  Suivant

Modèle de communication réseau

À un moment ou à un autre, vous aurez besoin de comprendre comment le client Subversion communique avec le serveur. La couche réseau de Subversion est abstraite, c'est-à-dire que les clients Subversion ont le même comportement quel que soit le type de serveur auquel ils ont affaire. Qu'ils communiquent via le protocole HTTP (http://) avec un serveur HTTP Apache ou via le protocole Subversion (svn://) avec svnserve, le modèle de communication réseau est le même. Dans cette section, nous expliquons les fondamentaux de ce modèle de communication réseau, y compris la façon dont Subversion gère les authentifications et les autorisations.

Requêtes et réponses

Le client Subversion passe la plupart de son temps à gérer des copies de travail. Cependant, quand il a besoin d'informations disponibles dans un dépôt distant, il envoie une requête sur le réseau et le serveur lui répond. Les détails du protocole réseau sont cachés à l'utilisateur : le client essaie d'accéder à une URL et, suivant le format de cette URL, utilise un protocole particulier pour contacter le serveur (voir la section intitulée « URL des dépôts Subversion »).

[Astuce] Astuce

Tapez svn --version pour voir quels types d'URL et de protocoles sont utilisables par votre client.

Quand le serveur reçoit une requête d'un client, il demande souvent au client de s'identifier. Il envoie un défi d'authentification vers le client et le client répond en fournissant les éléments d'authentification au serveur. Une fois cette authentification terminée, le serveur répond à la requête originale du client. Remarquez que ce fonctionnement est différent de celui de CVS où le client envoie systématiquement au préalable ses identifiants de connexion (procédure de « log in »), avant même de formuler la moindre requête. Dans Subversion, le serveur requiert explicitement l'authentification du client (par un défi d'authentification) au moment approprié, au lieu que ce soit le client qui s'authentifie a priori. Certaines opérations sont donc effectuées plus élégamment. Par exemple, si un serveur est configuré pour laisser tout le monde accéder au dépôt en lecture, alors le serveur n'envoie jamais de défi d'authentification quand un client tente un svn checkout.

Si une requête d'un client conduit à la création d'une nouvelle révision du dépôt (par exemple un svn commit), alors Subversion utilise le nom d'utilisateur fourni lors de la phase d'authentification comme auteur de la révision. C'est-à-dire que le nom d'utilisateur est stocké dans la propriété svn:author de la nouvelle révision (voir la section intitulée « Propriétés réservées à l'usage de Subversion »). Si le client n'a pas été authentifié (en d'autres termes, si le serveur n'a jamais envoyé de défi d'authentification), alors la propriété svn:author de la révision est vide.

Éléments d'authentification du client

Beaucoup de serveurs sont configurés afin de requérir une authentification. Parfois, les opérations de lecture sont autorisées aux utilisateurs anonymes alors que les opérations d'écriture nécessitent une authentification. Dans d'autres cas, à la fois les opérations de lecture et d'écriture requièrent une authentification. Les différentes options du serveur Subversion gèrent différents protocoles d'authentification mais, du point de vue de l'utilisateur, l'authentification se résume typiquement à un identifiant et un mot de passe. Les clients Subversion offrent différentes façon de gérer les éléments d'authentification de l'utilisateur, depuis la saisie interactive de l'identifiant et du mot de passe jusqu'à la mise en cache des éléments dans un conteneur chiffré ou non sur le disque.

Ici, le lecteur soucieux de sécurité va immédiatement bondir de son siège : « Mettre en cache des mots de passe sur le disque ? Quelle horreur ! Jamais ! ». Ne vous inquiétez pas outre mesure : ce n'est pas aussi terrible que ça en a l'air. Les paragraphes qui suivent vont détailler les différents types de cache pour les éléments d'authentification que Subversion utilise, les phases où il les utilise et comment désactiver cette fonctionnalité en totalité ou en partie.

Mise en cache des éléments d'authentification

Subversion propose une solution à ceux qui en ont assez de taper leur nom d'utilisateur et mot de passe à tout bout de champs. Par défaut, dès que le client texte interactif passe avec succès un défi d'authentification, les éléments d'authentification sont mis en cache sur le disque et associés à la combinaison du nom du serveur, son port et le domaine d'authentification. Ce cache sera automatiquement consulté lors des prochains défis, l'utilisateur n'ayant plus à retaper ses éléments d'authentification. Si aucun élément convenable n'est présent dans le cache, ou si les éléments du cache échouent à l'authentification, le client invitera l'utilisateur à fournir les informations nécessaires.

Les développeurs de Subversion reconnaissent que le stockage sur disque des éléments d'authentification peut consistuer une vulnérabilité. C'est pourquoi Subversion est capable de fonctionner avec les différents mécanismes offerts par le système d'exploitation et l'environnement de travail pour minimiser les risques de fuites d'information.

  • Sous Windows, le client Subversion stocke les mots de passe dans le répertoire %APPDATA%/Subversion/auth/. Sous Windows 2000 et ses successeurs, le client Subversion utilise les services cryptographiques standards de Windows pour chiffrer le mot de passe sur le disque. Comme la clé de chiffrement est gérée par Windows et qu'elle est associée à l'identifiant de connexion de l'utilisateur, lui seul peut déchiffrer le mot de passe en cache. Notez que si le mot de passe de l'utilisateur est réinitialisé par un administrateur, tous les mots de passe en cache deviennent indéchiffrables. Le client Subversion agit comme s'ils n'existaient pas, en redemandant le mot de passe quand c'est nécessaire.

  • De manière similaire, sur Mac OS X, le client Subversion stocke tous les mots de passe dans le jeton de connexion (géré par le service « Keychain »), qui est protégé par le mot de passe du compte utilisateur. La configuration des « préférences utilisateur » peut imposer une politique plus stricte, comme demander le mot de passe du compte utilisateur à chaque fois qu'un mot de passe Subversion est utilisé.

  • Pour les systèmes de type Unix, il n'existe pas de standard de service de type « Keychain ». Cependant, le client Subversion sait stocker de manière sûre les mots de passe en utilisant les services « Gnome Keyring », « KDE Wallet » et « GnuPG Agent ». Aussi, avant de stocker les mots de passe sans chiffrement dans la zone de cache ~/.subversion/auth/, le client Subversion demandera à l'utilisateur l'autorisation de le faire. Notez que la zone de cache auth/ reste protégée par les droits système et seul l'utilisateur (le propriétaire) des données peut les lire. Les droits sur les fichiers fournis par le système d'exploitation protègent les mots de passe vis-à-vis des autres utilisateurs non administrateurs sur le même système, pour autant qu'ils n'aient pas un accès physique direct au dispositif de stockage du répertoire de l'utilisateur ou aux sauvegardes.

Bien sûr, si vous êtes complètement paranoïaque, aucun de ces mécanismes n'est parfait. Ainsi, pour ceux qui sont prêts à sacrifier le confort d'utilisation au profit de la sécurité absolue, Subversion fournit de nombreuses façons de désactiver les systèmes de cache d'authentification.

Désactivation de la mise en cache des mots de passe

Quand vous effectuez une opération Subversion qui nécessite de vous authentifier, par défaut Subversion essaie de mettre en cache vos éléments d'authentification sur le disque sous une forme chiffrée. Sur certains systèmes, Subversion peut être incapable de chiffrer vos éléments d'authentification. Dans ce cas, Subversion vous demandera si vous voulez vraiment mettre en cache vos éléments d'authentification sur le disque sous forme claire :

$ svn checkout https://host.example.com:443/svn/private-repo
-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <https://host.example.com:443> Subversion Repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/tmp/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)?

Si vous voulez profiter de la facilité de ne pas avoir à entrer votre mot de passe à chaque nouvelle opération, vous pouvez répondre yes à cette invite. Si vous ne voulez pas stocker votre mot de passe en clair et que vous ne voulez pas que Subversion vous pose la question à chaque fois, vous pouvez désactiver la mise en cache en clair des mots de passe, soit de manière permanente, soit en fonction du serveur auquel vous vous connectez.

[Avertissement] Avertissement

Au moment de faire votre choix concernant la mise en cache des mots de passe, vérifier la politique de sécurité relative à votre poste de travail. Beaucoup d'entreprises ont des règles strictes sur le stockage des mots de passe de leurs employés.

Pour désactiver de manière permanente la mise en cache des mots de passe en clair, ajouter la ligne store-plaintext-passwords = no à la section [global] du fichier de configuration servers de votre machine locale. Pour la désactiver uniquement pour un serveur particulier, utiliser la même directive dans la section appropriée du fichier de configuration servers (pour plus de détails, reportez-vous à la section intitulée « Options de configuration » dans Chapitre 7, Personnalisation de Subversion.)

Pour désactiver la mise en cache des mots de passe pour les opérations en ligne de commande, utilisez l'option --no-auth-cache. Pour désactiver la mise en cache de manière permanente, ajoutez l'option store-passwords = no dans le fichier de configuration Subversion de votre machine.

Suppression des éléments d'authentification déjà en cache

Il arrive que les utilisateurs veuillent effacer certains mots de passe du cache disque. Pour ce faire, vous devez vous rendre dans la zone auth/ et effacer manuellement le fichier de cache approprié. Les éléments d'authentification sont mis en cache dans des fichiers individuels ; si vous affichez chaque fichier, vous voyez des clés et des valeurs. La clé svn:realmstring décrit le domaine du serveur auquel est associé le fichier :

$ ls ~/.subversion/auth/svn.simple/
5671adf2865e267db74f09ba6f872c28
3893ed123b39500bca8a0b382839198e
5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8
username
V 3
joe
K 8
password
V 4
blah
K 15
svn:realmstring
V 45
<https://svn.domaine.fr:443> dépôt de Paul
END

Une fois le bon fichier trouvé, effacez-le.

Authentification en ligne de commande

Toutes les opérations en ligne de commandes acceptent les options --username et --password, qui vous permettent de spécifier respectivement un nom d'utilisateur et un mot de passe afin que Subversion ne soit pas obligé de vous inviter à les entrer. C'est particulièrement pratique si vous devez invoquer Subversion dans un script et que vous ne pouvez pas vous fier au fait que Subversion trouvera des éléments d'authentification valides dans le cache pour vous. Ces options sont aussi utiles lorsque Subversion a déjà mis en cache les éléments d'authentification pour vous, mais que vous savez que vous ne voulez pas utiliser ces éléments. Vous pouvez omettre l'option --password si vous souhaitez que Subversion utilise seulement le nom d'utilisateur fourni mais continue à demander un mot de passe pour cet utilisateur.

Un dernier mot sur l'authentification

La façon dont svn gère l'authentification, avec un zoom sur les options --username et --password. Beaucoup de sous-commandes du client acceptent ces options, mais il est important de comprendre que l'utilisation de ces options n'envoie pas automatiquement les éléments d'authentification au serveur. Comme vu précédemment, le serveur demande explicitement l'authentification au client quand il estime que c'est nécessaire ; le client ne les envoie pas à sa convenance. Même si un nom d'utilisateur et/ou un mot de passe sont passés en option, ils ne sont envoyés au serveur que si celui-ci les demande. Ces options sont couramment utilisées pour s'authentifier sous un nom d'utilisateur différent de celui que Subversion aurait choisi par défaut (comme votre nom de compte système), ou quand on ne veut pas de commande interactive (par exemple, utilisation de la commande svn dans un script).

[Note] Note

Une erreur classique consiste à mal configurer un serveur de telle sorte qu'il n'envoie jamais de défi d'authentification. Quand les utilisateurs passent les options --username et --password, ils sont surpris de voir qu'elles ne sont jamais utilisées, c'est-à-dire que les nouvelles révisions semblent toujours avoir été propagées de façon anonyme !

En résumé, voici comment un client Subversion se comporte quand il reçoit un défi d'authentification :

  1. D'abord, le client vérifie si l'utilisateur a spécifié explicitement des éléments d'authentification dans la ligne de commande (options --username et/ou --password). Si c'est le cas, le client essaie de s'authentifier auprès du serveur avec ces éléménts.

  2. Si les éléments d'authentification ne sont pas passés en ligne de commande, ou si ceux qui ont été fournis ne sont pas valides, le client regarde dans la zone auth/ s'il trouve le nom, le port et le domaine du serveur pour voir si l'utilisateur a déjà les éléments d'authentification en cache. Si c'est le cas, il essaie d'utiliser ces éléments pour s'authentifier.

  3. Finalement, si les mécanismes précédents ont abouti à des échecs d'authentification sur le serveur, le client se résout à demander les éléments à l'utilisateur (à moins qu'il ne lui ait été indiqué de ne pas le faire via l'option --non-interactive ou son équivalent spécifique au client).

Si le client réussit à s'authentifier par l'une ou l'autre de ces méthodes, il essaie de mettre en cache les éléments d'authentification sur le disque (à moins que cette fonctionnalité ne soit désactivée, comme indiqué auparavant).

Précédent  Niveau supérieur  Suivant
Listes de modifications  Sommaire  Travail sans copie de travail