Używam snv + ssh z uwierzytelnianiem na podstawie klucza. W tej chwili, aby którykolwiek z moich użytkowników svn mógł uzyskać dostęp do repozytorium przez Subversion, muszę ustawić, aby pliki repo były czytelne i zapisywane w systemie plików dla tych użytkowników.
Chcę uniemożliwić użytkownikom usunięcie bazy danych repo po zalogowaniu się do serwera za pośrednictwem ssh, ale nadal będę mógł kasować i zatwierdzać kod.
Myśli, jak to zrobić?
Odpowiedzi:
Aby uzyskać dostęp do adresu URL svn + ssh, klient svn uruchamia instancję svnserve za pomocą „ssh -q użytkownik @ host svnserve -t” i rozmawia z tą instancją poprzez stdin / stdout.
Jeśli użytkownicy potrzebują normalnego dostępu ssh, nadal można uniemożliwić im dostęp do repozytorium, ograniczając dostęp do jednego użytkownika (chown -R svnserve: svnserve repo; chmod -R g-rwx, o-rwx repo) i zastępując polecenie svnserve przez ten program opakowujący setuid / setgid svnserve .
W środowisku użytkowników współużytkowanych poleciłbym skonfigurowanie prawdziwego serwera Subversion (albo svnservepoprzez Apache). W tym środowisku poszczególni użytkownicy wcale nie potrzebują dostępu do plików repozytorium, ponieważ cały dostęp do plików odbywa się na koncie użytkownika procesu serwera.
Książka Subversion zawiera sekcję Wybieranie konfiguracji serwera, która może pomóc. Z tej sekcji (moje wyróżnienie):
Jeśli masz istniejącą infrastrukturę w dużej mierze opartą na kontach SSH i jeśli użytkownicy mają już konta systemowe na twoim serwerze, warto wdrożyć rozwiązanie svnserve-over-SSH. W przeciwnym razie nie zalecamy tej opcji opinii publicznej. Zasadniczo uważa się za bezpieczniejszy dostęp użytkowników do repozytorium za pośrednictwem (fikcyjnych) kont zarządzanych przez svnserve lub Apache, a nie przez pełne konta systemowe.
Ta strona ma kilka fajnych sztuczek: http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks
Jeśli nic z tego nie działa, być może obejście może rozwiązać ten problem? Możesz wykonać kopię zapasową repozytorium za każdym razem, gdy ktoś coś popełnia, dodając coś takiego do przechwytywania zmian: sudo rsync -a / my / repo / path / my / closed / path /
Widzę dwa możliwe kierunki ataku tego problemu:
zgadzam się z Gregiem i Olafem - idź po dostęp do https. używam takiej konfiguracji od dłuższego czasu i naprawdę nie widzę żadnych jej wad.
zyskasz dodatkową korzyść z precyzyjnej kontroli dostępu w repozytorium - dzięki czemu niektóre jego części będą dostępne tylko do odczytu, a niektóre całkowicie niedostępne dla wybranych użytkowników.