2011-01-28 12 views
25

Uzyskujemy dostęp do udostępnionego repozytorium git za pośrednictwem ścieżek plików, z różnych powodów, których teraz pominąłem, utworzonych za pomocą --shared = group.Jak poprawnie używać uprawnień do plików grupowych w repozytorium git?

Mamy różne grupy uniksowe, ale wszystkie mają wspólną grupę. Jeśli uruchomię chgrp -R w repozytorium git, wszyscy będą mogli z niego czytać, ale jeśli ktoś napisze do niego częściej niż nie, tworzone są nowe pliki, które nie używają wspólnej grupy.

Ten problem wydaje się być, ponieważ nasza podstawowa grupa nie jest wspólna i jeśli uruchomimy nowy plik, wszystko wydaje się działać dobrze.

Są jednak problemy z tym podejściem; newgrp jest powolny i tworzy nową powłokę, co sprawia, że ​​myślenie wywoływanie jej w .bash_profile byłoby złym pomysłem, nawet bez zastanawiania się, czy chcielibyśmy, aby nasze nowe pliki używały wspólnej grupy. Opieranie się na pamięci, aby uruchomić ją przed wykonaniem jakiejkolwiek pracy git, wydaje się być również receptą na katastrofę.

Więc ... jakieś sugestie?

+2

Spróbuj 'gitolite', potrzebujesz tylko jednego użytkownika git. – takeshin

+6

Pobieranie innego oprogramowania nie jest dla nas opcją. – rich

Odpowiedz

21

Należy również ustawić grupę setgid bit.

 
chgrp -R GROUP /path/to/repo 
find /path/to/repo -type d -print0 | xargs -0 chmod g+s 
+7

Nigdy nie "chmod -R g + s" repozytorium git, zamiast robić tylko to, co myślałeś, że zrobiłeś, po prostu włączyłeś setgid na każdym pliku. – Arrowmaster

+0

To prawda, że ​​nie jest to najlepsze. Na szczęście żadna z nich nie jest wykonywalna. Zaktualizowałem post tylko do katalogów hitów (co jest wymagane). –

+2

Jeśli zamierzasz użyć find, możesz równie dobrze wypróbować i użyć -print0, aby chronić przed kimkolwiek na tyle szalonym, aby używać spacji lub innych dziwnych znaków w nazwach gałęzi/tagów. – Arrowmaster

7

Czy to nagie repo? Jeśli jest to nagłe repozytorium, którego używałeś, kiedy go tworzyłeś, to nie powinno się dziać, dlatego pytam.

Jeśli jest to nagie repo może niektóre katalogi zostały zmienione na g-s, jeśli tak się stało, musisz albo chmod g+x tylko wszystkie katalogi, upewnij się, że nie robisz tego do żadnych plików. Łatwiejszym sposobem na to jest ponowne zrobienie nowego repo i przeniesienie zawartości z klonu.

19

Istniejący repozytorium, który nie został stworzony z --shared można włączać wspólne stosując następujące polecenia:

# make the repository shared 
git config core.sharedRepository group # or whatever other sharing option 
# fix the setgid bit 
find . -type d | xargs chmod g+s 
# repair the permissions 
chmod -R g+r * 
+1

W moim przypadku musiałem zrobić "chmod -R g + rw *", ponieważ grupa powinna mieć prawo do pisania, a nie tylko czytać. W przeciwnym razie dziękuję za odpowiedź. –

4

musiałem użyć kombinacji z powyższych odpowiedzi:

git config core.sharedRepository group 
chgrp -R GROUP /path/to/repo 
find /path/to/repo -type d -exec chmod g+rwxs {} \; 
3

Gdy nagi repozytorium ma flagę shared=group, git zajmie się resztą, więc poniższe czynności należy wykonać tylko raz. Również setgid jest przestarzałe do tego zastosowania. Tu kopiuj/wklej my answer from serverfault:

Zakładając repogroup jest grupa, a masz cd do katalogu repo:

najpierw zmienić wspólną flagę group:

git config core.sharedRepository group 

Uwaga: tutaj musisz użyj słowa kluczowego group, a nie nazwy grupy. Jest to równoznaczne z tworzeniem gołego repozytorium z opcją --shared=group.

Następnie zmienić grupę dla całego repozytorium:

chgrp -R repogroup . 

Aby upewnić się, że istniejące katalogi są grupa zapisu (g+w) i istniejące pliki wykonywalne stać również Group-wykonywalne (g+X) trzeba także do:

chmod -R g+wX . 

Gdy już to zrobisz, git uhonoruje flagę shared=group i dbać o uprawnieniach grupy w następujący, b oth dla istniejących i nowych plików, więc już nigdy nie będziesz potrzebować ponownie do umask lub chgrp.

Wstawię źródło w komentarzu, jeśli znajdę go z powrotem.

Powiązane problemy