SVNBOOK Chap6 Path-Based Authorization
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.pathbasedauthz
Sommaire |
Path-Based Authorization
Path-Based Authorization
Contrôle d'accès basé sur les chemins
Both Apache and svnserve are capable of granting (or denying) permissions to users. Typically this is done over the entire repository: a user can read the repository (or not), and she can write to the repository (or not). It's also possible, however, to define finer-grained access rules. One set of users may have permission to write to a certain directory in the repository, but not others; another directory might not even be readable by all but a few special people.
Both servers use a common file format to describe these path-based access rules. In the case of Apache, one needs to load the mod_authz_svn module and then add the AuthzSVNAccessFile directive (within the httpd.conf file) pointing to your own rules file. (For a full explanation, see the section called “Per-directory access control”.) If you're using svnserve, you need to make the authz-db variable (within svnserve.conf) point to your rules file.
Apache et svnserve sont tous deux capables d'accorder ou de refuser l'accès aux utilisateurs. Généralement c'est géré globalement au niveau du dépôt : un utilisateur peut accéder (ou pas) au dépôt en lecture, et il peut accéder (ou pas) au dépôt en écriture. Il est pourtant aussi possible de définir des règles d'accès possédant une granularité plus fine. Un ensemble d'utilisateurs peut alors obtenir le droit d'écrire dans certains répertoires du dépôt, mais pas dans d'autres ; parallèlement, un autre répertoire peut très bien ne pas être accessible en lecture pour la majorité des utilisateurs.
Les deux types de serveurs utilisent un format de fichier commun pour décrire les règles d'accès basées sur les chemins. Dans le cas d'Apache, il faut charger le module mod_authz_svn puis ajouter la directive AuthzSVNAccessFile (dans le fichier httpd.conf) pointant vers votre propre fichier de règles (pour l'explication complète, voir le paragraphe intitulé "Contrôle d'accès par répertoire"). Si vous utilisez svnserve, vous devez faire pointer la variable authz-db (dans svnserve.conf) vers votre fichier de règles.
POINT OF INTEREST: Do You Really Need Path-Based Access Control?
- Do You Really Need Path-Based Access Control?
- Avez-vous vraiment besoin d'un contrôle d'accès basé sur les chemins ?
- A lot of administrators setting up Subversion for the first time tend to jump into path-based access control without giving it a lot of thought. The administrator usually knows which teams of people are working on which projects, so it's easy to jump in and grant certain teams access to certain directories and not others. It seems like a natural thing, and it appeases the administrator's desire to maintain tight control of the repository.
- Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced. Teams can sometimes spontaneously collaborate with each other; someone may want to help someone else out by committing to an area she doesn't normally work on. By preventing this sort of thing at the server level, you're setting up barriers to unexpected collaboration. You're also creating a bunch of rules that need to be maintained as projects develop, new users are added, and so on. It's a bunch of extra work to maintain.
- Remember that this is a version control system! Even if somebody accidentally commits a change to something she shouldn't, it's easy to undo the change. And if a user commits to the wrong place with deliberate malice, it's a social problem anyway, and that the problem needs to be dealt with outside Subversion.
- So, before you begin restricting users' access rights, ask yourself whether there's a real, honest need for this, or whether it's just something that “sounds good” to an administrator. Decide whether it's worth sacrificing some server speed, and remember that there's very little risk involved; it's bad to become dependent on technology as a crutch for social problems. [48]
- As an example to ponder, consider that the Subversion project itself has always had a notion of who is allowed to commit where, but it's always been enforced socially. This is a good model of community trust, especially for open source projects. Of course, sometimes there are truly legitimate needs for path-based access control; within corporations, for example, certain types of data really can be sensitive, and access needs to be genuinely restricted to small groups of people.
- De nombreux administrateurs qui mettent en place Subversion pour la première fois ont tendance à se lancer dans le contrôle d'accès basé sur les chemins sans trop y réfléchir. L'administrateur sait en général quelles équipes travaillent sur quel projet, il est dès lors facile de démarrer et d'accorder l'accès pour certains répertoires à certaines équipes et pas à d'autres. Ça peut sembler assez naturel, et apaiser le désir de l'administrateur de contrôler le dépôt de très près.
- Notez cependant qu'il y a souvent des coûts invisibles (et visibles !) associés à cette fonctionnalité. Dans la catégorie visible, le serveur doit faire beaucoup de travail pour s'assurer que l'utilisateur a le droit de lire ou d'écrire sur chaque chemin spécifié ; dans certaines situations, il y a une chute très significative des performances. Dans la catégorie invisible, réfléchissez à la culture que vous créez. La plupart du temps, même si certains utilisateurs ne devraient pas propager de modifications dans certaines parties du dépôt, ce contrat social n'a pas besoin de solution technologique pour être respecté. Les équipes peuvent parfois collaborer spontanément entre elles ; quelqu'un peut vouloir aider quelqu'un d'autre en effectuant une propagation dans une zone qui n'est pas celle où il travaille habituellement. En interdisant ce genre de choses au niveau du serveur, vous mettez en place une barrière à la collaboration. Vous créez aussi tout un tas de règles qui doivent être gérées au fur et à mesure que les projets se développent, que de nouveaux utilisateurs sont ajoutés, etc. C'est un quantité de travail supplémentaire à fournir.
- Souvenez-vous que c'est un système de gestion de versions ! Même si quelqu'un propageait accidentellement une modification là où il n'aurait pas du, revenir en arrière reste très facile. Et si un utilisateur propage au mauvais endroit de façon intentionnelle, c'est un problème social qui doit être réglé, de toute manière, en dehors de Subversion.
- Bref, avant que vous ne commenciez à restreindre les droits d'accès des utilisateurs, demandez-vous si cela correspond à un véritable besoin ou si c'est juste quelque chose qui "plaît" à l'administrateur. Demandez-vous si ça vaut la peine de sacrifier de la vitesse côté serveur et souvenez-vous que les risques associés sont très minimes ; ce n'est pas une bonne idée d'attendre de la technologie qu'elle résolve les problèmes sociaux [48].
- En guise d'exemple à méditer, prenez le cas du projet Subversion lui-même, au sein duquel il a toujours été clairement défini quel utilisateur avait le droit d'effectuer des propagations à tel endroit, règles qui ont toujours été appliquées socialement. C'est un bon modèle de confiance dans la communauté, en particulier pour les projets open source. Bien sûr, il peut parfois y avoir de véritables besoins légitimant un contrôle d'accès basé sur les chemins ; dans les grandes entreprises, par exemple, certaines données peuvent être sensibles et l'accès à ces données doit vraiment être restreint à un petit groupe de personnes.
Once your server knows where to find your rules file, it's time to define the rules.
The syntax of the file is the same familiar one used by svnserve.conf and the runtime configuration files. Lines that start with a hash (#) are ignored. In its simplest form, each section names a repository and path within it, as well as the authenticated usernames are the option names within each section. The value of each option describes the user's level of access to the repository path: either r (read-only) or rw (read/write). If the user is not mentioned at all, no access is allowed.
To be more specific: the value of the section names is either of the form [repos-name:path] or of the form [path]. If you're using the SVNParentPath directive, it's important to specify the repository names in your sections. If you omit them, a section such as [/some/dir] will match the path /some/dir in every repository. If you're using the SVNPath directive, however, it's fine to only define paths in your sections—after all, there's only one repository.
[calc:/branches/calc/bug-142] harry = rw sally = r
In this first example, the user harry has full read and write access on the /branches/calc/bug-142 directory in the calc repository, but the user sally has read-only access. Any other users are blocked from accessing this directory.
Une fois que votre serveur sait où trouver votre fichier de règles, il est temps de définir ces règles.
La syntaxe du fichier est la même syntaxe que celle utilisée dans svnserve.conf et dans les fichiers de configuration des exécutables. Les lignes commançant par un dièse (#) sont ignorées. Dans la forme la plus simple, chaque section désigne un dépôt et un chemin à l'intérieur de celui-ci, et les noms d'utilisateurs authentifiés sont les noms des options à l'intérieur de chaque section. La valeur de chaque option décrit le niveau d'accès au chemin du dépôt de l'utilsateur : soit r (lecture seule) soit rw (lecture/écriture). Si l'utilisateur ne figure pas dans la section, l'accès n'est pas autorisé.
Plus précisément, la valeur des noms de section est soit de la forme [nom-du-depot:chemin] soit de la forme [chemin]. Si vous utilisez la directive SVNParentPath, il est est important de spécifier les noms des dépôts dans vos sections. Si vous les omettez, une section telle que [/un/repertoire] correspondra au chemin /un/repertoire de tous les dépôts. Cependant, si vous utilisez la directive SVNPath, ne définir que des chemins dans vos sections est acceptable - après tout, il n'y a qu'un seul dépôt.
[calc:/branches/calc/bogue-142] harry = rw sally = r
Dans ce premier exemple, l'utilisateur harry a les droits d'accès complets en lecture/écriture au répertoire /branches/calc/bogue-142 du dépôt calc, mais l'utilisateur sally n'a que l'accès en lecture. Tous les autres utilisateurs sont bloqués et ne peuvent pas accéder à ce répertoire.
Of course, permissions are inherited from parent to child directory. That means we can specify a subdirectory with a different access policy for Sally:
[calc:/branches/calc/bug-142] harry = rw sally = r # give sally write access only to the 'testing' subdir [calc:/branches/calc/bug-142/testing] sally = rw
Now Sally can write to the testing subdirectory of the branch, but can still only read other parts. Harry, meanwhile, continues to have complete read/write access to the whole branch.
It's also possible to explicitly deny permission to someone via inheritance rules, by setting the username variable to nothing:
[calc:/branches/calc/bug-142] harry = rw sally = r [calc:/branches/calc/bug-142/secret] harry =
In this example, Harry has read/write access to the entire bug-142 tree, but has absolutely no access at all to the secret subdirectory within it.
Bien évidemment, les droits d'accès sont hérités d'un répertoire parent à ses fils. Ce qui signifie que nous pouvons spécifier un sous-répertoire avec une politique d'accès différente pour Sally :
[calc:/branches/calc/bogue-142] harry = rw sally = r # donne à sally les droits d'écriture sur le sous-répertoire "test" [calc:/branches/calc/bogue-142/test] sally = rw
Maintenant Sally peut écrire dans le sous-répertoire test de la branche, mais ne peut toujours que lire les autres parties. Harry, en attendant, continue à avoir les droits d'accès complets en lecture écriture sur toute la branche.
On peut aussi interdire explicitement l'accès à quelqu'un grâce aux régles d'héritage, en attribuant la valeur vide à un nom d'utilisateur :
[calc:/branches/calc/bogue-142] harry = rw sally = r [calc:/branches/calc/bogue-142/secret] harry =
Dans cet exemple, Harry a les droits de lecture/écriture sur l'arborescence bogue-142 toute entière, mais n'a absolument pas accès au répertoire secret qu'elle contient.
TIP
- The thing to remember is that the most specific path always matches first. The server tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.
- La chose à retenir est que le chemin le plus spécifique est choisi en premier. Le serveur tente de trouver une correspondance avec le chemin lui-même, puis avec son chemin parent, puis avec le parent du parent, etc. Le résultat est que tout chemin spécifié dans le fichier des accès prendra le pas sur les droits hérités de ses répertoires parents.
By default, nobody has any access to the repository at all. That means that if you're starting with an empty file, you'll probably want to give at least read permission to all users at the root of the repository. You can do this by using the asterisk variable (*), which means “all users”:
[/] * = r
This is a common setup; notice that no repository name is mentioned in the section name. This makes all repositories world-readable to all users. Once all users have read access to the repositories, you can give explicit rw permission to certain users on specific subdirectories within specific repositories.
The asterisk variable (*) is also worth special mention because it's the only pattern that matches an anonymous user. If you've configured your server block to allow a mixture of anonymous and authenticated access, all users start out accessing anonymously. The server looks for a * value defined for the path being accessed; if it can't find one, it demands real authentication from the client.
The access file also allows you to define whole groups of users, much like the Unix /etc/group file:
[groups] calc-developers = harry, sally, joe paint-developers = frank, sally, jane everyone = harry, sally, joe, frank, sally, jane
Groups can be granted access control just like users. Distinguish them with an “at” (@) prefix:
[calc:/projects/calc] @calc-developers = rw [paint:/projects/paint] jane = r @paint-developers = rw
Another important fact is that the first matching rule is the one which gets applied to a user. In the prior example, even though Jane is a member of the paint-developers group (which has read/write access), the jane = r rule will be discovered and matched before the group rule, thus denying Jane write access.
Groups can also be defined to contain other groups:
[groups] calc-developers = harry, sally, joe paint-developers = frank, sally, jane everyone = @calc-developers, @paint-developers
Par défaut, personne n'a accès au dépôt. Cela signifie que si vous démarrez avec un fichier vide, vous voudrez probablement au moins donner les droits de lecture sur la racine du dépôt à tous les utilisateurs. Vous pouvez accomplir ceci en utilisant la variable astérisque (*), qui signifie "tous les utilisateurs" :
[/] * = r
C'est une configuration très répandue ; notez qu'aucun nom de dépôt n'est mentionné dans le nom de la section. Ceci rend tous les dépôts accessibles en lecture à tous les utilisateurs. Une fois que tous les utilisateurs ont l'accès en lecture aux dépôts, vous pouvez accorder des droits d'écriture explicites à certains utilisateurs sur des sous-répertoires spécifiques à l'intérieur de dépôts spécifiques.
La variable astérisque (*) a aussi ceci de spécial qu'elle est le seul symbole qui puisse correspondre à un utilisateur anonyme. Si vous avez configuré votre serveur pour qu'il autorise un mélange d'accès anonymes et authentifiés, tous les utilisateurs peuvent commencer à y accéder anonymement. Le serveur cherche une valeur * définie pour le chemin d'accès demandé ; s'il n'en trouve pas, il demande au client de s'authentifier.
Le fichier des accès vous permet aussi de définir des groupes entiers d'utilisateurs, à la façon du fichier Unix /etc/group :
[groups] developpeurs-calc = harry, sally, joe developpeurs-paint = frank, sally, jane tout-le-monde = harry, sally, joe, frank, sally, jane
Les droits d'accès peuvent être accordés aux groupes de la même façon qu'à de simples utilisateurs. Il faut juste les mettre en évidence par le préfixe "at" (@) :
[calc:/projets/calc] @developpeurs-calc = rw [paint:/projets/paint] jane = r @developpeurs-paint = rw
Un autre fait notable est que la première règle vérifiée est celle qui sera appliquée à l'utilisateur. Dans l'exemple précédent, même si Jane est membre du groupes des développeurs paint (qui a les droits de lecture/écriture), la règle jane = r sera lue et vérifiée avant la règle du groupe, refusant ainsi à Jane l'accès en écriture.
Les groupes peuvent aussi contenir d'autres groupes :
[groups] developpeurs-calc = harry, sally, joe developpeurs-paint = frank, sally, jane tout-le-monde = @developpeurs, @developpeurs-paint
Subversion 1.5 brings another useful feature to the access file syntax: username aliases. Some authentication systems expect and carry relatively short usernames of the sorts we've been describing here—harry, sally, joe, and so on. But other authentication systems—such as those which use LDAP stores or SSL client certificates—may carry much more complex usernames. For example, Harry's username in an LDAP-protected system might be CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com. With usernames like that, the access file can become quite bloated with long or obscure usernames that are easy to mistype. Fortunately, username aliases allow you to have to type the correct complex username only once, in a statement which assigns to it a more easily digestable alias.
[aliases] harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com sally = CN=Sally Swatterbug,OU=Engineers,DC=red-bean,DC=com joe = CN=Gerald I. Joseph,OU=Engineers,DC=red-bean,DC=com ...
Once you've defined a set of aliases, you can refer to the users elsewhere in the access file via their aliases in all the same places you could have instead used their actual usernames. Simply prepend an ampersand to the alias to distinguish it from a regular username:
[groups] calc-developers = &harry, &sally, &joe paint-developers = &frank, &sally, &jane everyone = @calc-developers, @paint-developers
You might also choose to use aliases if your users' usernames change frequently. Doing so allows you to need to update only the aliases table when these username changes occur, instead of doing global-search-and-replace operations on the whole access file.
Subversion 1.5 introduisit une autre fonctionnalité utile pour la syntaxe du fichier d'accès : les alias. Certains systèmes d'authentification attendent et utilisent des noms d'utilisateurs relativement courts tels que ceux que nous avons décrits ici - harry, sally, joe, etc. Mais d'autres systèmes d'authentification, comme par exemple ceux qui utilisent des bases LDAP ou des certificats clients SSL, peuvent utiliser des noms d'utilisateurs beaucoup plus complexes. Par exemple, le nom d'utilisateur d'Harry dans un système protégé par LDAP pourrait très bien être : CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com (NDT : Harry s'appelle donc en fait "Harold Hacker" et est un des ingénieurs de la compagnie "red-bean"). Avec des noms d'utilisateurs de ce type, le fichiers des accès devient rapidement illisible, avec des noms d'utilisateurs longs ou obscurs qui peuvent facilement être mal orthographiés. Heureusement, les alias vous permettent de n'avoir à taper le nom d'utilisateur complexe entier qu'une seule fois, au sein d'un paragraphe qui lui attribue un alias bien plus digeste :
[aliases] harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com sally = CN=Sally Swatterbug,OU=Engineers,DC=red-bean,DC=com joe = CN=Gerald I. Joseph,OU=Engineers,DC=red-bean,DC=com ...
Une fois défini votre ensemble d'alias, vous pouvez faire référence à ces utilisateurs en d'autres endroits du fichier par leurs alias, partout là où vous auriez sinon entré leur véritables noms d'utilisateurs. Il faut juste ajouter une esperluette (&) juste avant l'alias pour le distinguer des noms d'utilisateurs classiques :
[groups] developpeurs-calc = &harry, &sally, &joe developpeurs-paint = &frank, &sally, &jane tout-le-monde = @developpeurs-calc, @developpeurs-paint
Vous pouvez aussi choisir d'utiliser des alias si les noms de vos utilisateurs changent souvent. Ainsi vous n'aurez que la table des alias à mettre à jour quand des modifications de noms d'utilisateurs auront lieu, au lieu d'avoir à effectuer des opérations de recherches-et-remplacements-globaux sur la totalité du fichier.
POINT OF INTEREST: Partial Readability and Checkouts
- Partial Readability and Checkouts
- Accès partiel en lecture et extractions
- If you're using Apache as your Subversion server and have made certain subdirectories of your repository unreadable to certain users, you need to be aware of a possible nonoptimal behavior with svn checkout.
- When the client requests a checkout or update over HTTP, it makes a single server request and receives a single (often large) server response. When the server receives the request, that is the only opportunity Apache has to demand user authentication. This has some odd side effects. For example, if a certain subdirectory of the repository is readable only by user Sally, and user Harry checks out a parent directory, his client will respond to the initial authentication challenge as Harry. As the server generates the large response, there's no way it can resend an authentication challenge when it reaches the special subdirectory; thus the subdirectory is skipped altogether, rather than asking the user to reauthenticate as Sally at the right moment. In a similar way, if the root of the repository is anonymously world-readable, the entire checkout will be done without authentication—again, skipping the unreadable directory, rather than asking for authentication partway through.
- Si vous utilisez Apache en tant que serveur Subversion, et que vous avez rendu certains sous-répertoires de votre dépôt inaccessibles en lecture à certains utilisateurs, vous devez être au courant d'un comportement potentiellement non-optimal de la commande svn checkout.
- Quand le client lance une requête de mise à jour ou d'extraction via HTTP, il envoie une requête unique au serveur et reçoit du serveur une réponse unique (dont la taille peut être assez importante). Quand le serveur reçoit la requête, c'est la seule opportunité dont dispose Apache pour demander à l'utilisateur de s'authentifier. Ceci a des effets secondaires assez étonnants. Par exemple, si un certain sous-répertoire du dépôt n'est accessible en lecture qu'à l'utilisateur Sally et qu'Harry extrait un répertoire parent, son client répondra à la demande d'authentification initiale en tant que Harry. Au fur et à mesure que le serveur génère la réponse, il n'a aucun moyen de renvoyer un défi d'authentification quand il atteint le sous-répertoire spécial ; ainsi le sous-répertoire tout entier est omis, plutôt que de demander à l'utilisateur de se ré-authentifier en tant que Sally le moment venu. De même, si la racine du dépôt est accessible en lecture anonymement, l'extraction se fera entièrement sans authentification - omettant, encore une fois, le répertoire non-lisible, plutôt que d'envoyer une demande d'authentification au cours de l'opération.
