Ветвительная директория с частичным доступом для чтения

Question

У меня есть svn-репозиторий, использующий authz для управления доступом. Структура выглядит следующим образом:

├── branches 
│   └── bob 
├── tags 
└── trunk 
    └── A 
     ├── B 
     │   └── README.txt 
     └── README.txt 

Пусть AuthZ предоставляет пользователю доступ к каталогу A но не B читать, и он терпит неудачу при попытке разветвляются A:

[hidden]$ svn copy A ^/branches/bob/A1 -m 'Branching A to branches/bob/A1' 
Adding copy of  A 
svn: E220001: Commit failed (details follow): 
svn: E220001: Access denied 

журнала The Svnserve говорит

Authorization Failed recursive read /trunk/A 

Почему у svn есть это ограничение и есть способ обойти? Почему он не игнорирует B при ветвлении, точно так же, как делать кассу?

Если это оказалось невозможным, тогда какой лучший рабочий процесс для svn с authz? Похоже, ветвление не разрешено, единственный способ - все, кто работает на багажнике, но это слишком глупо.

Answer 1

Первоначальная реализация authz SVN не проверила все поддеревья на копии, но объявление затем вышли на адрес this security hole.

Итак, вывод заключается в том, что authz SVN не был разработан с самого начала, рано или поздно вошло много хакерских и грязных исправлений, что в конечном итоге сделало ваш случай использования неподдерживаемым. ИМХО хорошая реализация должна просто отслеживать, откуда была скопирована ветка, и проверить authz источника.

Я согласен, что ваш прецедент полностью действителен, и Perforce поддерживает управление на основе пути довольно хорошо. К сожалению, вы не можете сделать это в svn. Вы можете переключиться на Perforce или дождаться их до improve authz.

Answer 2

У вас есть разрешение на запрет на поднод B для этого пользователя и запрет разрешений отменяет права на чтение.

Когда ветвление A, B невозможно пропустить (оно находится внутри A и, насколько известно или знает SVN, это часть его). Вот почему вы не можете этого сделать. На самом деле это хорошо, что это мешает вам, поскольку вы обычно не хотите, чтобы ветка пропускала папку из источника.

Не должно быть обходного пути для этого, это поведение имеет смысл. Для того, чтобы иметь действие филиальную успеха, вам необходимо либо:

• движение B за пределами
• дают пользователю доступ к А, и все, что под ним

Я понимаю, что могут быть случаи, когда это расстраивает, но если B - это то, что не зависит от A, или если кто-то, кто работает на A, не заботится о B или не нуждается в доступе к B - в таком случае B не должен быть действительно внутри A.