2010-05-17 8 views
6
Ubuntu: Jaunty 
Mercurial: 1.3.1 
Access: ssh (users john and bob) 
File permission: -rw-rw---- 1 john john 129276 May 17 13:28 dirstate 
User: bob 
Command: 'hg st' 
Response: 

**abort: Permission denied: /our/respository/.hg/dirstate** 

Ovviamente mercuriale non può permettere a bob di vedere lo stato perché il file che ha bisogno di leggere appartiene a me.Come impostare le autorizzazioni in modo che due utenti possano lavorare sullo stesso repository hg?

Quindi cambio le autorizzazioni per consentire a bob di leggere il file e tutto va bene, fino a quando non provo a fare qualcosa, da cui le situazioni sono invertite. Ora possiede il file e non riesco a leggerlo.

Così ho creato un gruppo di "committer" e sia john che bob appartengono al gruppo, ma ancora giocherelloni con la proprietà e le autorizzazioni ogni volta che uno o l'altro si impegna.

Inoltre, quando uno o l'altro di noi aggiunge un file al repository, il file è di proprietà esclusiva del committer. Per me va bene, dato che sono abbastanza familiare con chmod ma presenta un grosso problema a Bob quando trascuro di concedergli il permesso. Suppongo che abbiamo solo bisogno di un hook post-commit per questo; ma solo per includere questo sintomo ...

Come lo configuriamo in modo che due diversi accessi nello stesso gruppo possano eseguire il commit allo stesso repository su ssh?

risposta

1

A lungo termine la soluzione bituminosa non ha funzionato neanche.

Ciò che ha funzionato è inserire i comandi chmod/chgrp in uno script di bash e insegnare al progettista come eseguirlo.

#!/bin/bash 
chgrp -R foo /foo/development/templates 
chgrp -R foo /foo/development/media 
chgrp -R foo /foo/development/static 

chmod -R g+w /foo/development/templates 
chmod -R g+w /foo/development/media 
chmod -R g+w /foo/development/static 
3

utilizzando i gruppi unix: vedere il metodo del filesystem here.

13

È necessario impostare il "gruppo sticky bit" su tutte le directory pertinenti. Quel bit di autorizzazioni dice che qualsiasi file o directory creata in quelle directory dovrebbe avere la proprietà di gruppo del gruppo della directory genitore, non del gruppo principale dell'utente di creazione.

È possibile impostare le cose a posto andando al livello superiore di tutto il vostro repo (hg root) e di eseguire questi comandi:

chgrp -R committers . 
chmod -R ug+=rwX . 
find . -type d -print0 | xargs -0 chmod 2775 # or 2770 if other can't read 

Questo primo comando dà la proprietà del gruppo di nuovo a committers per tutti i file e le directory. Il secondo comando garantisce che i proprietari e i membri del gruppo possano leggere e scrivere tutti i file e le directory e che possano discendere tutte le directory. Il terzo comando elenca solo le directory (omettendo i file) e quindi imposta il bit del gruppo di barre su di esse. Dopo aver finito i permessi per le directory sarà: rwxrwsr-x

Devi farlo solo una volta, e se lo fai prima di creare il repository non hai bisogno di usare find dal momento che il bit di gruppo appiccicoso sarà ereditato da tutte le directory. È stato fatto allo stesso modo per CVS e svn nei vecchi tempi.

+1

Hai ragione. Il segreto è il bit appiccicoso ... "chmod g + s .hg .hg/store .hg/store/data" sembra aver reso le cose 'così-tanto-così-buone'. –

+0

Sì, questo sistemerà qualsiasi nuovo file aggiunto. Il resto di quella roba era solo per riparare i file già creati. –

Problemi correlati