2 votes

Définir les permissions SVN avec Dav SVN Authz

Il semble qu'il y ait un problème d'héritage de chemin d'accès qui me perturbe par rapport aux restrictions d'accès. Par exemple, si j'accorde rw l'accès à un groupe/utilisateur, et que vous souhaitez le restreindre à certains /../../secret à aucun, il me crache rapidement au visage.

Voici un exemple de ce que j'essaie de réaliser dans dav_svn.authz

[groups]
grp_W = a, b, c, g
grp_X = a, d, f, e
grp_Y = a, e,

[/]
* = 
@grp_Y = rw

[somerepo1:/projectPot]
@grp_W = rw

[somerepo2:/projectKettle]
@grp_X = rw

Ce qui est attendu : grp_Y tiene rw l'accès à tous les référentiels, tandis que grp_W y grp_X n'ont accès qu'à leurs référentiels respectifs.

Ce qui se passe : grp_Y a accès à tous les référentiels, tandis que grp_W y grp_X n'ont accès à rien

Si je renverse l'ordre d'accès en donnant l'accès à tout le monde et en le restreignant dans chaque dépôt, il ignore immédiatement la règle d'invalidation (suppression des droits) et donne à tout le monde l'accès accordé au niveau de la racine.

En renonçant aux groupes, il fait de même avec des dispositions spécifiques à l'utilisateur, même entièrement définies, comme par exemple :

[/]
a = rw
b = 
c = 
d = 
e =
f = 
g = rw

[somerepo1:/projectPot]
a = rw
b = rw
c = rw
d =
e = rw
f =
g = rw

[somerepo2:/projectKettle]
a = rw
b
c
d = rw
e = rw
f = rw
g

Ce qui donne exactement le même résultat. Selon le documentation Je suis tous les protocoles, alors c'est insensé.

Exécution sur Apache2 avec dav_svn

3voto

StudentKen Points 207

Après un tas de maux de tête, je l'ai laissé tourner au ralenti avec * = rw en SVNParentPath niveau. En y revenant, j'ai soudain eu un éclair de lucidité : l'ordre de lecture était le problème.

Tout d'abord, mes conventions d'appellation étaient carrément fausses, comme il se doit. [<repo_name>:<path-in-repo>]

Le problème principal est que le fichier authz attend un ordre de "spécificité" où la première règle lue, ou la première correspondance disponible, est appliquée. Dans mon cas, tout correspondrait à la racine et ce serait un-et-fini. Donc en inversant l'ordre de mon exemple :

[groups]
grp_W = a, b, c, g
grp_X = a, d, f, e
grp_Y = a, e,

[ProjectPot:/]
@grp_W = rw

[ProjectKettle:/]
@grp_X = rw

[/]
* = 
@grp_Y = rw

le ferait accepter et fonctionner comme il se doit. Ceci n'est PAS DOCUMENTÉ et, à mon avis, il s'agit d'un problème sérieux pour quelque chose de tout à fait trivial.

0voto

vinnyjames Points 373

J'ai rencontré le même problème il y a peu de temps et je n'ai pas réussi à trouver de solution. Quelques règles d'alias apache bon marché et/ou des définitions svn:external peuvent aider mais si cela devient modérément compliqué, je ne pense pas que vous puissiez le faire aujourd'hui. WANdisco a reçu un certain nombre de demandes pour cette fonctionnalité et il se peut qu'elle obtienne suffisamment d'élan pour mériter un authz amélioré avec un accès non hérité et le support des expressions régulières.

0voto

NCA Points 1

Vous devez donner l'url complète pour accéder au référentiel qui a la permission sinon vous devez donner la permission de lecture comme ceci.

[groups]
grp_W = a, b, c, g
grp_X = a, d, f, e
grp_Y = a, e,

[/]
* = 
@grp_Y = rw
@grp_w = r
@grp_x = r
[somerepo1:/projectPot]
@grp_W = rw

[somerepo2:/projectKettle]
@grp_X = rw

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X