Subversion créant des répertoires de révision avec des permissions trop strictes

Question

Ce matin, j'ai essayé de commettre une révision de Subversion et j'ai constaté que tout d'un coup je n'avais pas la permission de le faire.

Can't move '/svn/db/txn-protorevs/21000-ga9.rev' to '/svn/db/revs/21/21001': 
Permission Denied

Regarder le répertoire tours, je remarquai que quelqu'un avait commis la révision 21000e, et l'autorisation d'écriture de groupe pour le nouveau répertoire est manquant pour une raison quelconque.

 
    drwxrwsr-x 2 svn svn 24K 2008-10-27 10:04 19 
    drwxrwsr-x 2 svn svn 24K 2008-12-18 07:13 20 
    drwxr-sr-x 2 jeff svn 4.0K 2008-12-18 11:18 21 

La définition de l'autorisation d'écriture de groupe sur ce répertoire me permet de valider, donc je suis bon pour 1000 autres révisions. Mais pourquoi cela arrive-t-il et que puis-je changer pour m'assurer que cela ne se reproduise plus?

Answer 1

Si vous avez plus d'un développeur accédant au référentiel via le protocole file://, vous pouvez envisager de configurer un serveur Subversion (en utilisant svnserve ou Apache). Avec cette solution, le serveur lui-même est responsable de tous les accès et autorisations sur les fichiers du référentiel, et vous ne rencontrerez pas ce problème.

De l'SVN Book:

• Est-ce pas séduire par l'idée simple d'avoir tous vos utilisateurs accèdent à un référentiel directement via file:// URL. Même si le référentiel est facilement accessible à tous via un partage réseau, c'est une mauvaise idée. Il supprime toute couche de protection entre les utilisateurs et le référentiel: les utilisateurs peuvent accidentellement (ou intentionnellement) corrompre la base de données du référentiel, il devient difficile de mettre le référentiel hors ligne pour inspection ou mise à niveau et cela peut entraîner des problèmes de permissions. voir the section called “Supporting Multiple Repository Access Methods”). Notez que c'est aussi l'une des raisons pour lesquelles nous vous déconseillons d'accéder aux dépôts via les URL: du point de vue de la sécurité, c'est effectivement la même chose que pour les utilisateurs locaux via file://, et cela peut entraîner les mêmes problèmes si l'administrateur ne fait pas attention.

Answer 2

La cause la plus probable est comme dit Greg. Quelqu'un accède au référentiel via le protocole file: // et a un code trop restrictif umask.

Answer 3

La meilleure façon de résoudre ce problème consiste à accéder au référentiel via un serveur.

Si vous ne me dérange pas de communication non cryptée (ce qui semble être le cas puisque vous utilisez file://), svnserve est très facile à mettre en place:

svnserve -d -r /svn 

Voir this reference pour aider à sa mise en place et configurer l'authentification.

Le bummer est que vous devrez configurer l'authentification de chaque utilisateur séparément.

Pour vous connecter à l'authentification de votre système d'exploitation, vous devez configurer un serveur Apache SVN, ce qui est un peu plus compliqué, voir these general instructions. Vous pouvez trouver des instructions spécifiques pour votre système d'exploitation avec un peu de googling.Enfin, si vous voulez que la route la plus rapide empêche l'autorisation d'écriture du groupe en cours de réinitialisation tout en utilisant file://, demandez à tout le monde de définir un umask correct (002) ou utilisez svn via un script d'encapsulation le définissant :

#!/bin/bash 
# svnwrapper.sh 
umask 002 
/usr/bin/env svn $* 

Assurez-vous que cet umask n'est pas un problème de sécurité dans votre environnement.