Правила доступа к каталогу Mercurial - PullRequest
5 голосов
/ 13 августа 2011

У меня есть ртутный репозиторий со следующей структурой каталогов:

/
/system
/applications
/applications/client1
/applications/client2
/applications/client3

Я обслуживаю репо через поддомен apache через http (пока нет ssl) и хочу ограничить доступ для push, pull и commitконечно.Обычно я не хочу, чтобы некоторые пользователи вообще видели каталоги, а также не историю каталогов!

  1. Есть ли возможность ограничить доступ к каталогу в ртутном репозитории.
  2. Как я могу предоставить доступ к папке client 1 только для client1, client2 только для client2 в системе на основе linux? Примечание: Я не хочу разбивать хранилище на вложенные хранилища, если в этом нет необходимости!
  3. Если это не работает без вложенных хранилищ, кто-нибудь может подсказать, как это сделать с вложенными хранилищамиэтот случай с моей структурой каталогов.

Я потерян: (

Ответы [ 2 ]

4 голосов
/ 13 августа 2011

Поскольку у вас есть все в 1 хранилище, то нет.

tl; dr: Репозиторий всегда завершен, и если вы можете его клонировать, вы сможете увидеть все, нет способа ограничить доступ к контенту в локальном клоне, только к центральному серверу клон.


Сервер Mercurial может работать с авторизацией двумя способами:

  1. Может ограничивать доступ к хранилищу
  2. Он может использовать хуки, чтобы предотвратить отправку содержимого, которое пользователь не может изменять

Первый тип делает весь репозиторий доступным только для чтения или недоступным. Однако, если у пользователя есть доступ для чтения, он сможет клонировать и просмотреть весь репозиторий, историю и файлы.

Но вы могли бы запретить тому же пользователю изменять центральную копию, запретив ее толкание. Это будет означать, что этот пользователь может делать все, что он хочет, со своим собственным клоном, но он не сможет перенести эти изменения обратно в центральный клон.

Другой тип позволит вам контролировать, где изменения могут произойти, более детально. Однако обратите внимание, что пользователь снова сможет клонировать и увидеть весь репозиторий.

Кроме того, пользователь также сможет делать со своим личным клоном все, что захочет. Тем не менее, в то время как отправка в центральное хранилище не полностью запрещена с этим типом авторизации, ловушка будет смотреть на толкаемые наборы изменений, и если, скажем, вы решите, что этому пользователю не разрешено выдвигать изменения в контенте "client2", любые такие изменения, которые он пытается выдвинуть, будут прерваны.

Другими словами, пользователь может изменить свой личный клон, включая изменения в "client2", но если он фиксирует набор изменений с изменениями "client2", он не сможет вернуться обратно в центральный репозиторий. Затем ему придется раздеться или иначе избавиться от этих изменений, прежде чем его толчки пройдут.

Итак, подведем итог:

  1. Вы можете запретить пользователю вообще клонировать, это сделает весь репозиторий недоступным для него
  2. Вы можете запретить нажатия, но разрешить клонирование
  3. Вы можете использовать хуки для анализа входящих наборов изменений и предотвращения изменений в контенте, который пользователь не может изменять
  4. Независимо от того, если пользователь может создать клон, этот клон всегда является полным и неограниченным на компьютере пользователя. Вы не можете ограничить доступ к этому клону, все, что вы можете сделать, это пункт 1, запретить пользователю клонирование с самого начала.
1 голос
/ 12 мая 2012

Вы можете использовать расширение ACL , которое теперь распространяется по умолчанию с Mercurial.Расширение может ограничивать все действия Hg для каталога, без , прибегая к использованию под-репозиториев.

Кроме того, вы можете ограничить доступ на ветвь или на-folder .

...