SVNBOOK Chap6 svnserve, a Custom Server
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| SVF | Traduction | Fait | |
| Hotshot92 | 1ere Relecture | Fait | |
| Validation |
Source : http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.svnserve
Sommaire |
svnserve, a Custom Server
svnserve, a Custom Server
svnserve, un serveur sur mesure
The svnserve program is a lightweight server, capable of speaking to clients over TCP/IP using a custom, stateful protocol. Clients contact an svnserve server by using URLs that begin with the svn:// or svn+ssh:// scheme. This section will explain the different ways of running svnserve, how clients authenticate themselves to the server, and how to configure appropriate access control to your repositories.
Le programme svnserve est un serveur léger, capable de dialoguer avec des clients sur un réseau TCP/IP en utilisant un protocole dédié avec gestion des états. Les clients contactent le serveur svnserve en utilisant une URL qui commence par svn:// ou svn+ssh://. Cette section expliquera différentes mises en œuvre de svnserve, comment les clients s'authentifient sur le serveur et comment configurer un contrôle d'accès approprié pour vos dépôts.
Invoking the Server
Invoking the Server
Démarrer le serveur
There are a few different ways to run the svnserve program:
- Run svnserve as a standalone daemon, listening for requests.
- Have the Unix inetd daemon temporarily spawn svnserve whenever a request comes in on a certain port.
- Have SSH invoke a temporary svnserve over an encrypted tunnel.
- Run svnserve as a Microsoft Windows service.
Il existe différentes façons de démarrer le programme svnserve :
- lancer svnserve en tant que serveur autonome, à l'écoute de requêtes ;
- utiliser le démon Unix inetd pour lancer une instance temporaire de svnserve quand une requête arrive sur un port déterminé ;
- utiliser SSH pour lancer une instance temporaire de svnserve à travers un tunnel chiffré ;
- lancer svnserve en tant que service Microsoft Windows.
svnserve as daemon
svnserve as daemon
svnserve en serveur autonome
The easiest option is to run svnserve as a standalone “daemon” process. Use the -d option for this:
$ svnserve -d $ # svnserve is now running, listening on port 3690
When running svnserve in daemon mode, you can use the --listen-port and --listen-host options to customize the exact port and hostname to “bind” to.
Once we successfully start svnserve as explained previously, it makes every repository on your system available to the network. A client needs to specify an absolute path in the repository URL. For example, if a repository is located at /var/svn/project1, a client would reach it via svn://host.example.com/var/svn/project1. To increase security, you can pass the -r option to svnserve, which restricts it to exporting only repositories below that path. For example:
$ svnserve -d -r /var/svn ...
Using the -r option effectively modifies the location that the program treats as the root of the remote filesystem space. Clients then use URLs that have that path portion removed from them, leaving much shorter (and much less revealing) URLs:
$ svn checkout svn://host.example.com/project1 ...
L'option la plus facile est de démarrer svnserve en tant que serveur autonome. Pour le faire, utilisez l'option -d (d pour "démon") :
$ svnserve -d $ # svnserve est maintenant actif, en écoute sur le port 3690
Lorsque vous lancez svnserve en serveur autonome, vous pouvez utiliser les options --listen-port et --listen-host pour spécifier le port et l'adresse voulus pour "écouter".
Une fois le serveur démarré de cette manière, tous les dépôts présents sur votre machine seront accessibles par le réseau. Un client doit spécifier un chemin absolu dans l'URL du dépôt. Par exemple, si un dépôt est situé sous /var/svn/projet-1, un client l'atteindra avec svn://hote.exemple.com/var/svn/projet-1. Pour améliorer la sécurité, vous pouvez passer l'option -r à svnserve pour restreindre l'export aux dépôts situés sous le chemin indiqué. Par exemple :
$ svnserve -d -r /var/svn ...
L'utilisation de l'option -r modifie le chemin que le serveur considère comme la racine du système de fichiers à exporter. Les clients utiliseront alors des URL avec cette portion du chemin supprimée (ce qui rend les URL plus courtes et plus discrètes) :
$ svn checkout svn://hote.exemple.com/projet-1 ...
svnserve via inetd
svnserve via inetd
svnserve via inetd
If you want inetd to launch the process, you need to pass the -i (--inetd) option. In the following example, we've shown the output from running svnserve -i at the command line, but note that this isn't how you actually start the daemon; see the paragraphs following the example for how to configure inetd to start svnserve.
$ svnserve -i ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
When invoked with the --inetd option, svnserve attempts to speak with a Subversion client via stdin and stdout using a custom protocol. This is the standard behavior for a program being run via inetd. The IANA has reserved port 3690 for the Subversion protocol, so on a Unix-like system you can add lines to /etc/services such as these (if they don't already exist):
svn 3690/tcp # Subversion svn 3690/udp # Subversion
If your system is using a classic Unix-like inetd daemon, you can add this line to /etc/inetd.conf:
svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i
Make sure “svnowner” is a user that has appropriate permissions to access your repositories. Now, when a client connection comes into your server on port 3690, inetd will spawn an svnserve process to service it. Of course, you may also want to add -r to the configuration line as well, to restrict which repositories are exported.
Si vous désirez que inetd lance le processus, il vous faudra passer l'option -i (--inetd). Dans l'exemple suivant, nous avons voulu montrer le résultat de la commande svnserve -i, mais notez bien que ce c'est pas de cette manière que l'on démarre le démon ; reportez-vous aux paragraphes qui suivent l'exemple pour savoir comment configurer inetd pour qu'il démarre svnserve.
$ svnserve -i ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
Quand on l'invoque avec l'option --inetd, svnserve tente de communiquer avec un client Subversion via l'entrée et la sortie standards en utilisant un protocole spécifique. C'est le comportement habituel de tout programme lancé par inetd. L'IANA a réservé le port 3690 pour le protocole Subversion ; sur un système Unix vous pouvez donc ajouter au fichier /etc/services des lignes semblables à celles qui suivent (si elles n'existent pas déjà) :
svn 3690/tcp # Subversion svn 3690/udp # Subversion
Si votre système utilise un démon classique de type Unix, vous pouvez ajouter la ligne suivante à /etc/inetd.conf :
svn stream tcp nowait proprietairedesvn /usr/bin/svnserve svnserve -i
Assurez-vous que l'utilisateur "proprietairedesvn" possède des droits d'accès appropriés pour vos dépôts. Dès lors, quand une connexion client arrive sur le port 3690, inetd va générer un processus svnserve pour lui répondre. Bien sûr, vous pouvez également ajouter l'option -r à cette ligne de configuration, pour préciser quels dépôts doivent être exportés.
svnserve over a tunnel
svnserve over a tunnel
svnserve encapsulé
A third way to invoke svnserve is in tunnel mode, using the -t option. This mode assumes that a remote-service program such as rsh or ssh has successfully authenticated a user and is now invoking a private svnserve process as that user. (Note that you, the user, will rarely, if ever, have reason to invoke svnserve with the -t at the command line; instead, the SSH daemon does so for you.) The svnserve program behaves normally (communicating via stdin and stdout) and assumes that the traffic is being automatically redirected over some sort of tunnel back to the client. When svnserve is invoked by a tunnel agent like this, be sure that the authenticated user has full read and write access to the repository database files. It's essentially the same as a local user accessing the repository via file:// URLs.
This option is described in much more detail later in this chapter in the section called “Tunneling over SSH”.
Le mode tunnel est une troisième façon de lancer svnserve, via l'option -t. Ce mode présuppose qu'un programme de connexion à distance tel que rsh ou ssh a permis à un utilisateur de s'authentifier avec succès, et lance alors un processus privé svnserve pour le compte de cet utilisateur (remarquez qu'en tant qu'utilisateur vous aurez rarement, sinon jamais, l'occasion de lancer svnserve avec l'option -t en ligne de commande ; c'est le démon SSH qui le fait à votre place). Le programme svnserve se comporte alors normalement et suppose que le trafic est redirigé automatiquement vers le client par une sorte de tunnel. Quand svnserve est lancé par un gestionnaire de tunnel comme ici, soyez sans crainte : l'utilisateur authentifié possèdera les droits de lecture et d'écriture sur les fichiers de la base de données. C'est essentiellement la même chose que quand un utilisateur local accède au dépôt via des URL file://.
Cette option est décrite en détail plus loin dans ce chapitre, dans le paragraphe intitulé "Encapsuler svnserve dans SSH".
svnserve as Windows service
svnserve as Windows service
svnserve en tant que service Windows
If your Windows system is a descendant of Windows NT (2000, 2003, XP, or Vista), you can run svnserve as a standard Windows service. This is typically a much nicer experience than running it as a standalone daemon with the --daemon (-d) option. Using daemon mode requires launching a console, typing a command, and then leaving the console window running indefinitely. A Windows service, however, runs in the background, can start at boot time automatically, and can be started and stopped using the same consistent administration interface as other Windows services.
You'll need to define the new service using the command-line tool SC.EXE. Much like the inetd configuration line, you must specify an exact invocation of svnserve for Windows to run at startup time:
C:\> sc create svn
binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos"
displayname= "Subversion Server"
depend= Tcpip
start= auto
This defines a new Windows service named “svn,” which executes a particular svnserve.exe command when started (in this case, rooted at C:\repos). There are a number of caveats in the prior example, however.
Si votre système Windows est un descendant de Windows NT (2000, 2003, XP ou Vista), vous pouvez lancer svnserve en tant que service Windows. C'est généralement une expérience bien plus plaisante que de le lancer en démon indépendant via l'option --daemon (-d). Utiliser le mode démon nécessite de lancer une console, de taper une commande et ensuite de laisser la fenêtre de la console tourner indéfiniment. Un service Windows, au contraire, tourne à l'arrière-plan, peut être lancé automatiquement au démarrage, et peut être démarré et arrêté à l'aide de la même interface d'administration que les autres services Windows.
Vous devrez définir le nouveau service en utilisant l'outil en ligne de commande SC.EXE. De façon analogue à la ligne de configuration inetd, il faudra fournir la commande de lancement précise de svnserve pour que Windows le lance au démarrage :
C:\> sc create svn
binpath= "C:\svn\bin\svnserve.exe --service -r C:\depot"
displayname= "Serveur Subversion"
depend= Tcpip
start= auto
Ceci définit un nouveau service Windows nommé "svn", qui exécute un commande particulière svn.exe quand il démarre (dont la racine est, dans ce cas, C:\depot). Il y a un certain nombre de précautions à prendre avec cet exemple cependant.
First, notice that the svnserve.exe program must always be invoked with the --service option. Any other options to svnserve must then be specified on the same line, but you cannot add conflicting options such as --daemon (-d), --tunnel, or --inetd (-i). Options such as -r or --listen-port are fine, though. Second, be careful about spaces when invoking the SC.EXE command: the key= value patterns must have no spaces between key= and must have exactly one space before the value. Lastly, be careful about spaces in your command line to be invoked. If a directory name contains spaces (or other characters that need escaping), place the entire inner value of binpath in double quotes, by escaping them:
C:\> sc create svn
binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos"
displayname= "Subversion Server"
depend= Tcpip
start= auto
Also note that the word binpath is misleading—its value is a command line, not the path to an executable. That's why you need to surround it with quotes if it contains embedded spaces.
Once the service is defined, it can be stopped, started, or queried using standard GUI tools (the Services administrative control panel), or at the command line:
C:\> net stop svn C:\> net start svn
The service can also be uninstalled (i.e., undefined) by deleting its definition: sc delete svn. Just be sure to stop the service first! The SC.EXE program has many other subcommands and options; run sc /? to learn more about it.
Premièrement, remarquez que le programme svnserve.exe doit toujours être lancé avec l'option --service. Toute autre option de svnserve doit ensuite être spécifiée sur la même ligne, mais vous ne pouvez pas ajouter d'options qui seraient en conflit avec celle-ci, telles que --daemon (-d), --tunnel ou --inetd (-i). D'autres options, comme -r ou --listen-port, ne posent par contre pas de problème. Deuxièmement, faites attention aux espaces quand vous tapez la commande SC.EXE : les groupes "clé= valeur" ne doivent pas comporter d'espaces entre clé et = et doivent comporter exactement un espace avant la valeur. Enfin, faites attention aux espaces présents dans la ligne de commande que vous indiquez. Si le nom d'un répertoire contient des espaces (ou tout autre caractère qui ait besoin d'être banalisé), placez l'ensemble du contenu de binpath entre guillemets, qui doivent eux-mêmes être banalisés :
C:\> sc create svn
binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\depot"
displayname= "Serveur Subversion"
depend= Tcpip
start= auto
Notez aussi que le terme "binpath" prête à confusion : sa valeur est une ligne de commande, pas le chemin d'accès à un exécutable. C'est pourquoi vous devez l'entourer de guillemets s'il contient des espaces.
Une fois que le service a été crée, il peut être arrêté, démarré ou interrogé à l'aide des outils standards de l'interface graphique (le panneau de configuration des services administratifs), ou en ligne de commande :
C:\> net stop svn C:\> net start svn
Le service peut aussi être désinstallé (c'est-à-dire supprimé) en effaçant sa définition : sc delete svn. Prenez soin d'arrêter le service auparavant ! Le programme SC.EXE possède de nombreuses autres sous-commandes ; tapez sc /? en ligne de commande pour en savoir plus.
Built-in Authentication and Authorization
Built-in Authentication and Authorization
Authentification et contrôle d'accès intégrés
When a client connects to an svnserve process, the following things happen:
- The client selects a specific repository.
- The server processes the repository's conf/svnserve.conf file and begins to enforce any authentication and authorization policies it describes.
- Depending on the defined policies, one of the following may occur:
- The client may be allowed to make requests anonymously, without ever receiving an authentication challenge.
- The client may be challenged for authentication at any time.
- If operating in tunnel mode, the client will declare itself to be already externally authenticated (typically by SSH).
The svnserve server, by default, knows only how to send a CRAM-MD5 [41] authentication challenge. In essence, the server sends a small amount of data to the client. The client uses the MD5 hash algorithm to create a fingerprint of the data and password combined, and then sends the fingerprint as a response. The server performs the same computation with the stored password to verify that the result is identical. At no point does the actual password travel over the network.
If your svnserve server was built with SASL support, it not only knows how to send CRAM-MD5 challenges, but also likely knows a whole host of other authentication mechanisms. See the section called “Using svnserve with SASL” later in this chapter to learn how to configure SASL authentication and encryption.
It's also possible, of course, for the client to be externally authenticated via a tunnel agent, such as ssh. In that case, the server simply examines the user it's running as, and uses this name as the authenticated username. For more on this, see the later section, the section called “Tunneling over SSH”.
As you've already guessed, a repository's svnserve.conf file is the central mechanism for controlling authentication and authorization policies. The file has the same format as other configuration files (see the section called “Runtime Configuration Area”): section names are marked by square brackets ([ and ]), comments begin with hashes (#), and each section contains specific variables that can be set (variable = value). Let's walk through these files and learn how to use them.
Lorsqu'un client se connecte au processus svnserve, les choses suivantes se passent :
- Le client sélectionne un répertoire particulier.
- Le serveur analyse le fichier conf/svnserve.conf de ce dépôt et commence à suivre les politiques d'authentification et de contrôle d'accès qui y sont décrites.
- Selon les politiques définies, une des choses suivantes a lieu :
- Le client est autorisé à lancer des requêtes anonymes, sans jamais recevoir le moindre défi d'authentification.
- Le client peut recevoir un défi d'authentification à tout instant.
- Si l'on est en mode tunnel, le client déclare lui-même avoir déjà satisfait à une authentification externe (généralement par SSH).
Le serveur svnserve ne sait envoyer, par défaut, que des défis d'authentification CRAM-MD5 [41]. Plus précisément, le serveur envoie une petite quantité de données aux clients. Le client utilise l'algorithme de hachage MD5 pour créer une empreinte combinant les données et le mot de passe, puis renvoie l'empreinte en guise de réponse. Le serveur effectue le même calcul avec le mot de passe enregistré pour vérifier que le résultat est identique. Le mot de passe ne circule ainsi jamais en clair sur le réseau.
Si votre serveur svnserve a été compilé en incluant le support de SASL, non seulement il sait comment envoyer des défis CRAM-MD5, mais il connaît aussi probablement un grand nombre d'autres mécanismes d'authentification. Consultez le paragraphe intitulé "Utiliser svnserve avec SASL" plus loin dans ce chapitre pour savoir comment configurer l'authentification et le chiffrement avec SASL.
Le client peut bien sûr aussi être authentifié en externe par un gestionnaire de tunnel tel que ssh. Dans ce cas, le serveur se contente de prendre l'identifiant par lequel il a été lancé et de s'en servir comme utilisateur authentifié. Pour plus de détails, reportez-vous plus loin au paragraphe "Encapsuler svnserve dans SSH".
Vous avez sûrement déjà deviné que le fichier svnserve.conf est le mécanisme central qui contrôle les politiques d'authentification et de contrôle d'accès. Ce fichier a le même format que d'autres fichiers de configuration (voir le paragraphe intitulé "Zone de configuration des exécutables") : les noms de paragraphes sont entourés de crochets ([ et ]), les lignes de commentaires commencent par des dièses (#) et chaque paragraphe contient des variables spécifiques qui peuvent être définies (variable = valeur). Examinons ces fichiers, et apprenons à les utiliser.
Create a users file and realm
Create a users file and realm
Création d'un fichier utilisateurs et d'un domaine d'authentification
For now, the [general] section of svnserve.conf has all the variables you need. Begin by changing the values of those variables: choose a name for a file that will contain your usernames and passwords and choose an authentication realm:
[general] password-db = userfile realm = example realm
The realm is a name that you define. It tells clients which sort of “authentication namespace” they're connecting to; the Subversion client displays it in the authentication prompt and uses it as a key (along with the server's hostname and port) for caching credentials on disk (see the section called “Client Credentials Caching”). The password-db variable points to a separate file that contains a list of usernames and passwords, using the same familiar format. For example:
[users] harry = foopassword sally = barpassword
The value of password-db can be an absolute or relative path to the users file. For many admins, it's easy to keep the file right in the conf/ area of the repository, alongside svnserve.conf. On the other hand, it's possible you may want to have two or more repositories share the same users file; in that case, the file should probably live in a more public place. The repositories sharing the users file should also be configured to have the same realm, since the list of users essentially defines an authentication realm. Wherever the file lives, be sure to set the file's read and write permissions appropriately. If you know which user(s) svnserve will run as, restrict read access to the users file as necessary.
Pour ce qui suit, le section [general] de svnserve.conf contient toutes les variables dont vous avez besoin. Commencez par modifier les valeurs de toutes les variables : choisissez un nom pour le fichier qui contiendra vos noms d'utilisateur et mots de passe et choisissez un domaine d'authentification :
[general] password-db = fichier-utilisateurs realm = exemple de domaine
Le domaine est un nom que vous définissez. Il indique aux clients à quelle sorte d'"espace de noms" ils se connectent ; le client Subversion l'affiche dans l'invite d'authentification et l'utilise comme clé (en combinaison avec le nom de machine et le port du serveur) pour mettre en cache les éléments d'authentification sur le disque (voir le paragraphe intitulé "Mise en cache des éléments d'authentification du client"). La variable password-db pointe vers un fichier séparé qui contient une liste de noms d'utilisateurs et de mots de passe, utilisant le même format usuel. Par exemple :
[users] harry = motdepassemachin sally = motdepassebidule
La valeur de password-db peut correspondre à un chemin absolu ou à un chemin relatif pour le fichier des utilisateurs. Pour de nombreux administrateurs, conserver le fichier dans la zone conf/ du dépôt, aux côtés de svnserve.conf, est une solution simple et facile. D'un autre côté, il se pourrait que deux dépôts, voire plus, doivent partager le même fichier ; dans ce cas, le fichier devrait sans doute être situé dans un répertoire plus accessible. Les dépôts partageant le même fichier utilisateurs devraient aussi être configurés de sorte qu'ils soient dans le même domaine, puisque la liste des utilisateurs définit, par essence, un domaine d'authentification. Quel que soit l'emplacement du fichier, faites attention à positionner les droits en lecture/écriture de façon appropriée. Si vous savez sous quel nom d'utilisateur svnserve fonctionnera, restreignez l'accès au fichier utilisateurs en conséquence.
Set access controls
Mise en place du contrôle d'accès
There are two more variables to set in the svnserve.conf file: they determine what unauthenticated (anonymous) and authenticated users are allowed to do. The variables anon-access and auth-access can be set to the value none, read, or write. Setting the value to none prohibits both reading and writing; read allows read-only access to the repository, and write allows complete read/write access to the repository. For example:
[general] password-db = userfile realm = example realm # anonymous users can only read the repository anon-access = read # authenticated users can both read and write auth-access = write
Il y a deux variables supplémentaires à définir dans le fichier svnserve.conf : elles déterminent ce que les utilisateurs non-authentifiés (anonymes) et les utilisateurs authentifiés ont le droit de faire. Les variables anon-access et auth-access peuvent contenir les valeurs none, read ou write. Choisir none empêche à la fois lecture et écriture ; read autorise l'accès en lecture seule au dépôt et write autorise l'accès complet en lecture/écriture au dépôt. Par exemple :
[general] password-db = fichier-utilisateurs realm = exemple de domaine # les utilisateurs anonymes ne peuvent accéder au dépôt qu'en lecture anon-access = read # les utilisateurs authentifiés peuvent à la fois lire et écrire auth-access = write
The example settings are, in fact, the default values of the variables, should you forget to define them. If you want to be even more conservative, you can block anonymous access completely:
[general] password-db = userfile realm = example realm # anonymous users aren't allowed anon-access = none # authenticated users can both read and write auth-access = write
The server process understands not only these “blanket” access controls to the repository, but also finer-grained access restrictions placed on specific files and directories within the repository. To make use of this feature, you need to define a file containing more detailed rules, and then set the authz-db variable to point to it:
[general] password-db = userfile realm = example realm # Specific access rules for specific locations authz-db = authzfile
We discuss the syntax of the authzfile file in detail later in this chapter, in the section called “Path-Based Authorization”. Note that the authz-db variable isn't mutually exclusive with the anon-access and auth-access variables; if all the variables are defined at once, all of the rules must be satisfied before access is allowed.
Les lignes présentes dans le fichier contiennent en fait les valeurs par défaut des variables, au cas où vous oublieriez de les définir. Si vous voulez être encore plus prudent, vous pouvez complètement interdire les accès anonymes :
[general] password-db = fichier-utilisateurs realm = exemple de domaine # les utilisateurs anonymes ne sont pas autorisés anon-access = none # les utilisateurs authentifiés peuvent à la fois lire et écrire auth-access = write
Le processus serveur sait interpréter non seulement ce contrôle d'accès générique, mais aussi des restrictions d'accès plus fines associées à des fichiers et répertoires spécifiques du dépôt. Pour utiliser cette fonctionnalité, vous devez définir un fichier contenant des règles plus détaillées, puis faire pointer la variable authz-db vers ce fichier :
[general] password-db = fichier-utilisateurs realm = exemple de domaine # Règles d'accès propres à certains emplacements authz-db = fichier-authz
Nous étudierons la syntaxe du fichier authz plus loin dans ce chapitre, dans le paragraphe intitulé "Contrôle d'accès basé sur les chemins". Notez que la variable authz-db n'est pas mutuellement exclusive avec les variables anon-access et auth-access ; si toutes les variables sont définies en même temps, toutes les règles doivent être satisfaites pour que l'accès soit autorisé.
Using svnserve with SASL
Using svnserve with SASL
Utilisation de svnserve avec SASL
For many teams, the built-in CRAM-MD5 authentication is all they need from svnserve. However, if your server (and your Subversion clients) were built with the Cyrus Simple Authentication and Security Layer (SASL) library, you have a number of authentication and encryption options available to you.
Pour de nombreuses équipes, l'authentification par CRAM-MD5 suffit à leurs besoins. Cependant, si votre serveur (et vos clients Subversion) ont été compilés avec la bibliothèque "Cyrus Simple Authentication and Security Layer" (SASL), vous avez à votre disposition un certain nombre d'options d'authentification et de chiffrement.
POINT OF INTEREST: What Is SASL?
- What Is SASL?
- Qu'est-ce que SASL ?
- The Cyrus Simple Authentication and Security Layer is open source software written by Carnegie Mellon University. It adds generic authentication and encryption capabilities to any network protocol, and as of Subversion 1.5 and later, both the svnserve server and svn client know how to make use of this library. It may or may not be available to you: if you're building Subversion yourself, you'll need to have at least version 2.1 of SASL installed on your system, and you'll need to make sure that it's detected during Subversion's build process. If you're using a prebuilt Subversion binary package, you'll have to check with the package maintainer as to whether SASL support was compiled in. SASL comes with a number of pluggable modules that represent different authentication systems: Kerberos (GSSAPI), NTLM, One-Time-Passwords (OTP), DIGEST-MD5, LDAP, Secure-Remote-Password (SRP), and others. Certain mechanisms may or may not be available to you; be sure to check which modules are provided.
- You can download Cyrus SASL (both code and documentation) from http://asg.web.cmu.edu/sasl/sasl-library.html.
- Cyrus Simple Authentication and Security Layer (signifiant "Couche d'authentification et de sécurité simple") est un logiciel libre qui a été écrit par l'université Carnegie Mellon. Il ajoute des possibilités d'authentification et de chiffrement à n'importe quel protocole réseau et, à partir de la version 1.5 de Subversion, le serveur svnserve et le client Subversion sont tous les deux capables de se servir de cette bibliothèque. Elle peut ne pas être à votre disposition : si vous compilez Subversion vous-même, il vous faudra au minimum la version 2.1 de SASL d'installée sur votre système et vous devrez vous assurer qu'elle est bien prise en compte durant le processus de compilation de Subversion. Si vous utilisez un paquet binaire précompilé de Subversion, vous devrez vérifier auprès de celui qui maintient ce paquet si SASL a été inclus à la compilation. SASL est fourni avec de nombreux modules optionnels qui représentent différents systèmes d'authentification : Kerberos (GSSAPI), NTLM, One-Time-Passwords (OTP), DIGEST-MD5, LDAP, Secure-Remote-Password (SRP) et d'autres encore. Certains mécanismes seront disponibles, d'autres pas ; pensez à vérifier quels modules sont inclus.
- Vous pouvez télécharger Cyrus SASL (à la fois le code et la documentation) à l'adresse http://asg.web.cmu.edu/sasl/sasl-library.html.
Normally, when a subversion client connects to svnserve, the server sends a greeting that advertises a list of the capabilities it supports, and the client responds with a similar list of capabilities. If the server is configured to require authentication, it then sends a challenge that lists the authentication mechanisms available; the client responds by choosing one of the mechanisms, and then authentication is carried out in some number of round-trip messages. Even when SASL capabilities aren't present, the client and server inherently know how to use the CRAM-MD5 and ANONYMOUS mechanisms (see the section called “Built-in Authentication and Authorization”). If server and client were linked against SASL, a number of other authentication mechanisms may also be available. However, you'll need to explicitly configure SASL on the server side to advertise them.
Normalement, quand un client Subversion se connecte à svnserve, le serveur envoie un message de bienvenue qui liste les fonctionnalités qu'il supporte et le client répond avec une liste similaire. Si le serveur est configuré pour exiger une authentification, il envoie ensuite un défi listant les mécanismes d'authentification disponibles ; le client répond en choisissant un des mécanismes et l'authentification se déroule ensuite par quelques échanges de messages. Même quand SASL n'est pas présent dans la liste, le client et le serveur sont capables d'utiliser les mécanismes CRAM-MD5 et ANONYMOUS (voir le paragraphe "Authentification et contrôle d'accès intégrés"). Si le serveur et le client ont été compilés pour inclure SASL, un certain nombre d'autres mécanismes d'authentification seront éventuellement disponibles. Néanmoins, vous devrez configurer explicitement SASL sur le serveur pour qu'ils soient proposés.
Authenticating with SASL
Authenticating with SASL
Authentification par SASL
To activate specific SASL mechanisms on the server, you'll need to do two things. First, create a [sasl] section in your repository's svnserve.conf file with an initial key-value pair:
[sasl]
use-sasl = true
Second, create a main SASL configuration file called svn.conf in a place where the SASL library can find it—typically in the directory where SASL plug-ins are located. You'll have to locate the plug-in directory on your particular system, such as /usr/lib/sasl2/ or /etc/sasl2/. (Note that this is not the svnserve.conf file that lives within a repository!)
On a Windows server, you'll also have to edit the system registry (using a tool such as regedit) to tell SASL where to find things. Create a registry key named [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library], and place two keys inside it: a key called SearchPath (whose value is a path to the directory containing the SASL sasl*.dll plug-in libraries), and a key called ConfFile (whose value is a path to the parent directory containing the svn.conf file you created).
Because SASL provides so many different kinds of authentication mechanisms, it would be foolish (and far beyond the scope of this book) to try to describe every possible server-side configuration. Instead, we recommend that you read the documentation supplied in the doc/ subdirectory of the SASL source code. It goes into great detail about every mechanism and how to configure the server appropriately for each. For the purposes of this discussion, we'll just demonstrate a simple example of configuring the DIGEST-MD5 mechanism. For example, if your subversion.conf (or svn.conf) file contains the following:
pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/my_sasldb mech_list: DIGEST-MD5
you've told SASL to advertise the DIGEST-MD5 mechanism to clients and to check user passwords against a private password database located at /etc/my_sasldb. A system administrator can then use the saslpasswd2 program to add or modify usernames and passwords in the database:
$ saslpasswd2 -c -f /etc/my_sasldb -u realm username
Pour activer les mécanismes spécifiques à SASL sur le serveur, il faut faire deux choses. D'abord, créez un paragraphe [sasl] dans le fichier svnserve.conf de votre dépôt avec le couple clé/valeur initial :
[sasl]
use-sasl = true
Ensuite, créez le fichier principal de configuration de SASL, appelé svn.conf, à un endroit où la bibliothèque SASL saura le trouver - généralement dans un répertoire où sont situés les greffons SASL. Vous devrez localiser le répertoire des greffons de votre système, tel que /usr/lib/sasl2/ ou /etc/sasl2/ (notez qu'il ne s'agit pas là du fichier svnserve.conf qui réside dans votre dépôt !).
Sur un serveur Windows vous devez aussi éditer la base de registre (à l'aide d'un outil tel que regedit) pour indiquer à SASL les emplacements où chercher. Créez une clé nommée [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library] et placez-y deux clés : l'une appelée SearchPath (dont la valeur est le chemin du répertoire contenant les bibliothèques de greffons SASL sasl*.dll) et l'autre appelée ConfFile (dont la valeur est le chemin du répertoire parent contenant le fichier svn.conf que vous avez créé).
Parce que SASL fournit de très nombreux mécanismes d'authentification, il serait insensé (et bien au-delà du cadre de ce livre) d'essayer de décrire toutes les configurations serveurs possibles. Nous vous recommandons plutôt de lire la documentation fournie dans le sous-répertoire doc/ du code source de SASL. Elle décrit en détail chaque mécanisme, ainsi que la manière de configurer le serveur correctement pour chacun d'entre eux. Dans ce paragraphe, nous nous contenterons de donner un exemple simple de configuration du mécanisme DIGEST-MD5. Par exemple, si votre fichier subversion.conf (ou svn.conf) contient ce qui suit :
pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/ma_bdd_sasl mech_list: DIGEST-MD5
vous demandez à SASL de proposer le mécanisme DIGEST-MD5 aux clients et de comparer les mots de passe des utilisateurs à une base de mots de passe privée située à l'emplacement /etc/ma_bdd_sasl. Un administrateur système pourra ensuite utiliser le programme saslpasswd2 pour ajouter ou modifier les noms d'utilisateurs et les mots de passe contenus dans cette base de données :
$ saslpasswd2 -c -f /etc/ma_bdd_sasl -u domaine utilisateur
A few words of warning: first, make sure the “realm” argument to saslpasswd2 matches the same realm you've defined in your repository's svnserve.conf file; if they don't match, authentication will fail. Also, due to a shortcoming in SASL, the common realm must be a string with no space characters. Finally, if you decide to go with the standard SASL password database, make sure the svnserve program has read access to the file (and possibly write access as well, if you're using a mechanism such as OTP).
This is just one simple way of configuring SASL. Many other authentication mechanisms are available, and passwords can be stored in other places such as in LDAP or a SQL database. Consult the full SASL documentation for details.
Remember that if you configure your server to only allow certain SASL authentication mechanisms, this forces all connecting clients to have SASL support as well. Any Subversion client built without SASL support (which includes all pre-1.5 clients) will be unable to authenticate. On the one hand, this sort of restriction may be exactly what you want (“My clients must all use Kerberos!”). However, if you still want non-SASL clients to be able to authenticate, be sure to advertise the CRAM-MD5 mechanism as an option. All clients are able to use CRAM-MD5, whether they have SASL capabilities or not.
Quelques consignes de prudence : tout d'abord, l'argument "domaine" qui est passé à saslpasswd2 doit correspondre au même domaine que vous avez défini dans le fichier svnserve.conf de votre dépôt ; s'ils ne correspondent pas, l'authentification échouera. En outre, à cause d'une limitation de SASL, ce domaine commun doit être une chaîne sans espace. Enfin, si vous décidez d'utiliser la base de données standard de mots de passe SASL, assurez-vous que le programme svnserve a accès en lecture à ce fichier (et éventuellement aussi en écriture, si vous utilisez un mécanisme tel que OTP).
Ceci est une manière simple de configurer SASL. De nombreux autres mécanismes d'authentification sont disponibles et les mots de passe peuvent être conservés dans des conteneurs différents, par exemple des annuaires LDAP ou des bases de données SQL. Reportez-vous à la documentation complète de SASL pour plus de détails.
Souvenez-vous que si vous configurez votre serveur pour qu'il n'autorise que certains mécanismes d'authentification SASL, tous les clients qui se connecteront auront l'obligation de supporter SASL. Tout client Subversion compilé sans SASL (ce qui inclut tous les clients antérieurs à la version 1.5) sera incapable de se connecter. D'un autre côté, ce type de restriction est peut-être exactement ce que vous recherchez ("Mes clients doivent tous utiliser Kerberos !"). Néanmoins, si vous voulez permettre à des clients non-SASL de se connecter, pensez bien à inclure le mécanisme CRAM-MD5 dans les choix possibles. Tous les clients savent utiliser CRAM-MD5, qu'ils aient des fonctionnalités SASL ou pas.
SASL encryption
SASL encryption
Chiffrement SASL
SASL is also able to perform data encryption if a particular mechanism supports it. The built-in CRAM-MD5 mechanism doesn't support encryption, but DIGEST-MD5 does, and mechanisms such as SRP actually require use of the OpenSSL library. To enable or disable different levels of encryption, you can set two values in your repository's svnserve.conf file:
[sasl] use-sasl = true min-encryption = 128 max-encryption = 256
The min-encryption and max-encryption variables control the level of encryption demanded by the server. To disable encryption completely, set both values to 0. To enable simple checksumming of data (i.e., prevent tampering and guarantee data integrity without encryption), set both values to 1. If you wish to allow—but not require—encryption, set the minimum value to 0, and the maximum value to some bit length. To require encryption unconditionally, set both values to numbers greater than 1. In our previous example, we require clients to do at least 128-bit encryption, but no more than 256-bit encryption.
SASL est également capable d'effectuer le chiffrement des données si un mécanisme particulier le supporte. Le mécanisme intégré CRAM-MD5 ne supporte pas le chiffrement, mais DIGEST-MD5 le supporte, et d'autres mécanismes tels que SRP requièrent l'utilisation de la bibliothèque OpenSSL. Pour activer ou désactiver différents niveaux de chiffrement, vous pouvez définir deux variables dans le fichier svnserve.conf de votre dépôt :
[sasl] use-sasl = true min-encryption = 128 max-encryption = 256
Les variables min-encryption et max-encryption contrôlent le niveau de chiffrement exigé par le serveur. Pour désactiver complètement le chiffrement, mettez les deux valeurs à 0. Pour activer une simple somme de contrôle sur les données (par exemple pour empêcher toute manipulation douteuse et garantir l'intégrité des données sans chiffrement), mettez les deux valeurs à 1. Si vous voulez autoriser le chiffrement, sans que ce soit obligatoire, mettez 0 pour la valeur minimale et un nombre de bits donné pour la valeur maximale. Pour exiger un chiffrement inconditionnel, mettez les deux valeurs à un nombre plus grand que 1. Dans l'exemple précédent, nous obligeons les clients à utiliser au moins un chiffrement 128 bits et au plus un chiffrement 256 bits.
Tunneling over SSH
Tunneling over SSH
Encapsulation de svnserve dans SSH
svnserve's built-in authentication (and SASL support) can be very handy, because it avoids the need to create real system accounts. On the other hand, some administrators already have well-established SSH authentication frameworks in place. In these situations, all of the project's users already have system accounts and the ability to “SSH into” the server machine.
It's easy to use SSH in conjunction with svnserve. The client simply uses the svn+ssh:// URL scheme to connect:
$ whoami harry $ svn list svn+ssh://host.example.com/repos/project harryssh@host.example.com's password: ***** foo bar baz ...
In this example, the Subversion client is invoking a local ssh process, connecting to host.example.com, authenticating as the user harryssh (according to SSH user configuration), then spawning a private svnserve process on the remote machine running as the user harryssh. The svnserve command is being invoked in tunnel mode (-t), and its network protocol is being “tunneled” over the encrypted connection by ssh, the tunnel agent. If the client performs a commit, the authenticated username harryssh will be used as the author of the new revision.
L'authentification intégrée (ainsi que SASL) peuvent être très pratiques, car ils évitent d'avoir à créer de véritables comptes systèmes. D'un autre côté, certains administrateurs ont déjà des systèmes d'authentification bien établis en place. Dans ce cas, tous les utilisateurs du projet possèdent déjà des comptes systèmes et peuvent se connecter au serveur par SSH.
Utiliser SSH en conjonction avec svnserve est facile. Le client utilise juste une URL svn+ssh:// pour se connecter :
$ whoami harry $ svn list svn+ssh://hote.exemple.com/depot/projet harryssh@hote.exemple.com's password: ***** truc machin bidule ...
Dans cet exemple, le client Subversion lance un processus local ssh, se connecte à hote.exemple.com, s'authentifie en tant que harryssh (en accord avec la configuration SSH des utilisateurs) puis génère un processus svnserve privé sur la machine distante, processus dont le propriétaire est l'utilisateur harryssh. La commande svnserve est lancée en mode tunnel (-t) et son protocole réseau est encapsulé dans la connexion chiffrée par ssh, le gestionnaire de tunnel. Si le client effectue une propagation, l'auteur de la nouvelle révision sera l'utilisateur authentifié.
The important thing to understand here is that the Subversion client is not connecting to a running svnserve daemon. This method of access doesn't require a daemon, nor does it notice one if present. It relies wholly on the ability of ssh to spawn a temporary svnserve process, which then terminates when the network connection is closed.
When using svn+ssh:// URLs to access a repository, remember that it's the ssh program prompting for authentication, and not the svn client program. That means there's no automatic password-caching going on (see the section called “Client Credentials Caching”). The Subversion client often makes multiple connections to the repository, though users don't normally notice this due to the password caching feature. When using svn+ssh:// URLs, however, users may be annoyed by ssh repeatedly asking for a password for every outbound connection. The solution is to use a separate SSH password-caching tool such as ssh-agent on a Unix-like system, or pageant on Windows.
When running over a tunnel, authorization is primarily controlled by operating system permissions to the repository's database files; it's very much the same as if Harry were accessing the repository directly via a file:// URL. If multiple system users are going to be accessing the repository directly, you may want to place them into a common group, and you'll need to be careful about umasks (be sure to read the section called “Supporting Multiple Repository Access Methods” later in this chapter). But even in the case of tunneling, you can still use the svnserve.conf file to block access, by simply setting auth-access = read or auth-access = none. [42]
Ce qu'il est important de comprendre ici est que le client Subversion ne se connecte pas à un démon svnserve fonctionnant en permanence. Cette méthode d'accès ne requiert pas la présence d'un démon, ni ne vérifie s'il y en a un qui tourne. Elle se base entièrement sur la capacité de SSH à générer un processus svnserve temporaire, qui ensuite se termine une fois la connexion SSH close.
Quand vous utilisez des URL svn+ssh:// pour accéder à un dépôt, souvenez-vous que c'est le programme ssh qui envoie l'invite d'authentification, pas le client Subversion. Ce qui signifie qu'il n'y a pas de mise en cache automatique de mots de passe (voir la paragraphe "Mise en cache des éléments d'authentification du client"). Le fonctionnement du client Subversion fait qu'il accède souvent au dépôt par des connexions multiples, bien que les utilisateurs ne s'en rendent habituellement pas compte grâce à la fonctionnalité de mise en cache du mot de passe. Lorsque vous utilisez des URL svn+ssh://, cependant, les utilisateurs risquent de trouver ça pénible que ssh demande le mot de passe de façon répétitive pour toute connexion vers l'extérieur. La solution est d'utiliser un outil séparé de mise en cache du mot de passe, tel que ssh-agent sur Unix ou pageant sur Windows.
Quand le trafic passe par un tunnel, les accès sont contrôlés principalement par les droits sur les fichiers de la base de données liés au système d'exploitation ; c'est quasiment pareil que si Harry accédait au dépôt directement via une URL file://. Si plusieurs utilisateurs systèmes accèdent au dépôt directement, il serait de bon ton de les placer dans un même groupe, et vous devrez faire attention aux umasks (prenez soin de lire le paragraphe "Autoriser plusieurs méthodes d'accès au dépôt" plus loin dans ce chapitre). Mais même dans le cas de l'encapsulation, vous pouvez toujours utiliser le fichier svnserve.conf pour bloquer l'accès, en spécifiant juste auth-access = read ou auth-access = none [42]).
You'd think that the story of SSH tunneling would end here, but it doesn't. Subversion allows you to create custom tunnel behaviors in your runtime config file (see the section called “Runtime Configuration Area”.) For example, suppose you want to use RSH instead of SSH. [43] In the [tunnels] section of your config file, simply define it like this:
[tunnels] rsh = rsh
And now, you can use this new tunnel definition by using a URL scheme that matches the name of your new variable: svn+rsh://host/path. When using the new URL scheme, the Subversion client will actually be running the command rsh host svnserve -t behind the scenes. If you include a username in the URL (e.g., svn+rsh://username@host/path), the client will also include that in its command (rsh username@host svnserve -t). But you can define new tunneling schemes to be much more clever than that:
[tunnels] joessh = $JOESSH /opt/alternate/ssh -p 29934
This example demonstrates a couple of things. First, it shows how to make the Subversion client launch a very specific tunneling binary (the one located at /opt/alternate/ssh) with specific options. In this case, accessing an svn+joessh:// URL would invoke the particular SSH binary with -p 29934 as arguments—useful if you want the tunnel program to connect to a nonstandard port.
Second, it shows how to define a custom environment variable that can override the name of the tunneling program. Setting the SVN_SSH environment variable is a convenient way to override the default SSH tunnel agent. But if you need to have several different overrides for different servers, each perhaps contacting a different port or passing a different set of options to SSH, you can use the mechanism demonstrated in this example. Now if we were to set the JOESSH environment variable, its value would override the entire value of the tunnel variable—$JOESSH would be executed instead of /opt/alternate/ssh -p 29934.
On pourrait s'attendre à ce que cette histoire d'encapsulation SSH se termine ici, mais ce n'est pas le cas. Subversion vous permet de créer des comportements d'encapsulation personnalisés dans votre fichier de configuration des exécutables (voir le paragraphe intitulé "Zone de configuration des exécutables"). Par exemple, supposons que vous vouliez utiliser RSH au lieu de SSH [43]. Dans le paragraphe [tunnels] de votre fichier de configuration, définissez-le comme ceci :
[tunnels] rsh = rsh
A présent vous pouvez utiliser cette nouvelle définition d'encapsulation par le biais d'un schéma d'URL qui correspond au nom de votre nouvelle variable : svn+rsh://hote/chemin. Lorsqu'il utilisera le nouveau type d'URL, le client Subversion va en fait lancer en arrière-plan la commande rsh hote svnserve -t. Si vous incluez un nom d'utilisateur dans l'URL(par exemple svn+rsh://nomdutilisateur@hote/chemin), le client va l'inclure dans sa commande (rsh nomdutilisateur@hote svnserve -t). Mais vous pouvez définir des schémas d'encapsulation bien plus évolués que ça :
[tunnels] paulssh = $PAULSSH /opt/alternate/ssh -p 29934
Cette exemple illustre plusieurs choses. D'abord, il indique comment faire pour que le client Subversion lance un exécutable d'encapsulation particulier (celui situé à l'emplacement /opt/alternate/ssh) avec des options particulières. Dans ce cas, se connecter à une URL svn+paulssh:// lancerait un exécutable SSH particulier avec les arguments -p 29934 (utile si vous voulez que le programme d'encapsulation se connecte à un port non standard).
Ensuite, il indique comment définir une variable d'environnement personnalisée capable de remplacer le nom du programme d'encapsulation. Configurer la variable d'environnement SVN_SSH est un moyen simple de modifier le programme d'encapsulation par défaut. Mais s'il vous faut différents programmes d'encapsulation pour différents serveurs, chacun se connectant par exemple à un port différent ou passant des options différentes à SSH, vous pouvez utiliser le mécanisme illustré dans cet exemple. Concrètement, si nous donnions une valeur à la variable d'environnement PAULSSH, cette valeur remplacerait la totalité de la valeur de la variable d'encapsulation - $PAULSSH serait exécuté au lieu de /opt/alternate/ssh -p 29934.
SSH configuration tricks
SSH configuration tricks
Astuces de configuration de SSH
It's possible to control not only the way in which the client invokes ssh, but also to control the behavior of sshd on your server machine. In this section, we'll show how to control the exact svnserve command executed by sshd, as well as how to have multiple users share a single system account.
Il est possible de contrôler non seulement la manière dont le client lance ssh, mais aussi le comportement de sshd sur votre machine. Dans ce paragraphe, nous indiquerons comment contrôler la commande svnserve précise qui est exécutée par sshd, ainsi que comment faire pour que plusieurs utilisateurs partagent un même compte système.
Initial setup
Initial setup
Mise en oeuvre initiale
To begin, locate the home directory of the account you'll be using to launch svnserve. Make sure the account has an SSH public/private keypair installed, and that the user can log in via public-key authentication. Password authentication will not work, since all of the following SSH tricks revolve around using the SSH authorized_keys file.
If it doesn't already exist, create the authorized_keys file (on Unix, typically ~/.ssh/authorized_keys). Each line in this file describes a public key that is allowed to connect. The lines are typically of the form:
ssh-dsa AAAABtce9euch… user@example.com
The first field describes the type of key, the second field is the base64-encoded key itself, and the third field is a comment. However, it's a lesser known fact that the entire line can be preceded by a command field:
command="program" ssh-dsa AAAABtce9euch… user@example.com
When the command field is set, the SSH daemon will run the named program instead of the typical tunnel-mode svnserve invocation that the Subversion client asks for. This opens the door to a number of server-side tricks. In the following examples, we abbreviate the lines of the file as:
command="program" TYPE KEY COMMENT
Pour commencer, localisez le répertoire "home" du compte utilisateur que vous utiliserez pour lancer svnserve. Assurez-vous que ce compte a un bi-clé de clés publique/privée et que l'utilisateur peut se connecter en s'authentifiant par la méthode à clé publique. L'authentification par mot de passe ne fonctionnera pas, puisque toutes les astuces SSH qui suivent consistent à utiliser le fichier SSH authorized_keys.
S'il n'existe pas déjà, créez le fichier authorized_keys (sur Unix, c'est généralement ~/.ssh/authorized_keys). Chaque ligne de ce fichier décrit une clé publique autorisée à se connecter. Ces ligne sont généralement de la forme :
ssh-dsa AAAABtce9euch… utilisateur@exemple.com
Le premier champ décrit le type de clé, le second champ est la clé elle-même, encodée en base 64, et le troisième champ est un commentaire. Cependant, c'est un fait moins connu que la ligne toute entière peut être précédée par un champ de commande :
command="programme" ssh-dsa AAAABtce9euch… utilisateur@exemple.com
Quand le champ de commande est présent, la démon SSH va lancer le programme indiqué au lieu de lancer l'habituel svnserve en mode tunnel que le client Subversion a demandé. En découlent un certain nombre d'astuces côté serveur. Dans les exemples suivantes, nous abrègerons les lignes du fichier par :
command="programme" TYPE CLÉ COMMENTAIRE
Controlling the invoked command
Controlling the invoked command
Contrôle de la commande à exécuter
Because we can specify the executed server-side command, it's easy to name a specific svnserve binary to run and to pass it extra arguments:
command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
In this example, /path/to/svnserve might be a custom wrapper script around svnserve which sets the umask (see the section called “Supporting Multiple Repository Access Methods”.) It also shows how to anchor svnserve in a virtual root directory, just as one often does when running svnserve as a daemon process. This might be done either to restrict access to parts of the system, or simply to relieve the user of having to type an absolute path in the svn+ssh:// URL.
It's also possible to have multiple users share a single account. Instead of creating a separate system account for each user, generate a public/private key pair for each person. Then place each public key into the authorized_users file, one per line, and use the --tunnel-user option:
command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com
This example allows both Harry and Sally to connect to the same account via public key authentication. Each of them has a custom command that will be executed; the --tunnel-user option tells svnserve to assume that the named argument is the authenticated user. Without --tunnel-user, it would appear as though all commits were coming from the one shared system account.
A final word of caution: giving a user access to the server via public-key in a shared account might still allow other forms of SSH access, even if you've set the command value in authorized_keys. For example, the user may still get shell access through SSH or be able to perform X11 or general port forwarding through your server. To give the user as little permission as possible, you may want to specify a number of restrictive options immediately after the command:
command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com
Note that this all must be on one line—truly on one line—since SSH CLÉ files do not even allow the conventional backslash character (\) for line continuation. The only reason we've shown it with a line break is to fit it on the physical page of a book.
Comme nous pouvons spécifier la commande exécutée côté serveur, il devient facile de désigner un exécutable svnserve spécifique et d'y passer des arguments supplémentaires :
command="/chemin/vers/svnserve -t -r /racine/virtuelle" TYPE CLÉ COMMENTAIRE
Dans cet exemple, /chemin/vers/svnserve/ pourrait être un script personnalisé construit autour de svnserve qui spécifierait le umask à utiliser (voir le paragraphe intitulé "Autoriser plusieurs méthodes d'accès au dépôt"). Il indique aussi comment comment "ancrer" svnserve dans un répertoire racine virtuel, ce qui est aussi très souvent utilisé quand svnserve fonctionne en tant que démon. Le but est soit de restreindre l'accès à certaines parties du système, soit simplement d'éviter que l'utilisateur ait à taper un chemin absolu dans l'URL svn+ssh://.
Il est également possible d'avoir plusieurs utilisateurs partageant un compte utilisateur unique. Au lieu de créer un compte système distinct pour chaque utilisateur, générez plutôt un bi-clé de clés publique/privée pour chaque personne. Placez ensuite chaque clé publique dans le fichier authorized_keys, une par ligne, et utilisez l'option --tunnel-user :
command="svnserve -t --tunnel-user=harry" TYPE1 CLÉ1 harry@exemple.com command="svnserve -t --tunnel-user=sally" TYPE2 CLÉ2 sally@exemple.com
Cet exemple permet à la fois à Harry et à Sally de se connecter au même compte utilisateur avec l'authentification via leur clé publique. Chacun d'eux doit exécuter une commande qui lui est propre ; l'option --tunnel-user signale à svnserve que l'argument fourni doit être considéré comme le nom de l'utilisateur authentifié. Sans --tunnel-user, toutes les propagations sembleraient venir du même compte utilisateur partagé.
Finalement, un dernier avertissement : autoriser l'accès d'un utilisateur au serveur via une clé publique dans un compte partagé n'empêche pas forcément d'autres formes d'accès SSH, même si vous avez spécifié une valeur pour le champ command dans authorized_keys. Par exemple, l'utilisateur aura toujours accès au shell via SSH, ou sera capable d'effectuer de la redirection X11 ou de la redirection d'un port quelconque de votre serveur. Pour accorder le moins de droits possibles à l'utilisateur, vous pouvez spécifier des options de restriction immédiatement après la commande :
command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-for warding,no-X11-forwarding,no-pty TYPE1 CLÉ1 harry@exemple.com
Notez bien que tout ceci doit tenir sur une seule ligne, vraiment sur une seule ligne, car les fichiers SSH authorized_keys n'autorisent même pas le caractère habituel de continuation de ligne (\). L'unique raison pour laquelle nous avons rajouté une coupure est pour que cela tienne dans le format physique d'un livre.
