Nella gestione di base di un repository SubVersion, per piccoli team di sviluppo, di solito ci si limita a dare accesso in lettura/scrittura a tutti gli sviluppatori coinvolti. A volte però c'è la necessità di configurare una serie di regole di accesso più articolate.
Supponiamo di aver già creato un repository (servito da svnserve) nel quale sono presenti due progetti: uno di nome "stuff" e l'altro di nome "nil" con la seguente struttura:
/
|- stuff
| |-branches
| | |- performance
| | \- RELEASE_1_0
| |- tags
| \- trunk
\- nil
|- branches
|- tags
\- trunk
Adesso facciamo finta di avere due gruppi di sviluppo:
- il gruppo1 (utenti dev1 e dev2) ha pieno accesso al progetto "stuff"
- il gruppo2 (utenti dev3 e dev4) ha pieno accesso al progetto "nil"
- abbiamo poi un utente supervisore che ha accesso in lettura ad entrambi i progetti
- uno sviluppatore (utente dev5) che ha accesso in sola lettura sul progetto "stuff" ma in lettura/scrittura sul branch "performance"
Vediamo come configurare svn per avere la politica di accesso indicata andando a modicare i file di configurazione nella cartella conf del repository:
Indichiamo al server SVN di utilizzare un file delle password di nome passwd ed un file delle ACL di nome authz:
--- file: svnserve.conf ---
[general]
# L'accesso anonimo al repository viene disabilitato
anon-access = none
auth-access = write
# Questa direttiva indica quale è il file delle password
password-db = passwd
# Questa direttiva abilita le ACLs
authz-db = authz
# Nome del realm
realm = nomeDelRealm
Nel file delle password configuriamo tutti gli utenti, inserendo un utente per ogni riga nella forma nomeUtente=passwordUtente
--- file: passwd ---
[users]
dev1=password1
dev2=password2
dev3=password3
dev4=password4
dev5=password5
supervisore=passwordDelSupervisore
A questo punto definiamo le ACL:
--- file: authz ---
[groups]
# definiamo i team di sviluppo
g1=dev1, dev2
g2=dev3, dev4
# diamo al supervisore il permesso di leggere tutto quello
# c'è nel repository
[/]
supervisore = r
# il gruppo g1 può leggere/scrivere sul progetto struff
# l'utente dev5 può solo leggere
[/stuff]
@g1 = rw
dev5 = r
# l'utente dev5 può leggere/scrivere sul branch performance del progetto stuff
[/stuff/branches/performance]
dev5 = rw
# il gruppo g2 può leggere/scrivere sul progetto nil
[/nil]
@g2 = rw
In pratica abbiamo definito dei gruppi di utenti nella sezione groups e poi inserito una entry del tipo [percorso] per ogni path da proteggere (attenzione, per definire ACL su repository diversi usare la sintassi [nomeRepository:percorso]).
Notate che:
-
i commenti iniziano per #
-
per ogni path si può indicare una o più regole
-
le regole sono del tipo soggetto=permesso
-
i permessi possono essere "r" (lettura) oppure "rw" (lettura/scrittura)
-
i soggetti possono essere:
-
* indica tutti gli utenti (quindi ad esempio *=r indica permesso di lettura per chiunque)
-
$autenticated indica gli utenti autenticati
-
$anonymous indica gli utenti NON autenticati
-
utente indica l'utente
-
@gruppo indica un gruppo
-
nei soggetti potete usare la tilde "~" per indicare una negazione: quindi ~$authenticated indica un utente non autenticato, ~@gruppo1 indica chiunque non faccia parte del gruppo1,
NOTA: è possibile avere qualche altra informazione sulle ACL qui (in questa guida vengo trattati anche gli alias, di cui non abbiamo parlato in questo articolo).