Хранение прав доступа к файлам в хранилище Subversion

Question

Как вы храните права доступа к файлам в хранилище? Несколько файлов должны быть доступны только для чтения, чтобы остановить сторонние программы от их уничтожения, но после извлечения из хранилища они настроены на чтение и запись.

Я посмотрел в Google и нашел сообщение в блоге за 2005 , в котором говорится, что Subversion не хранит права доступа к файлам. В списке есть патчи и скрипты-хуки (все еще существует только один URL). Три года спустя Subversion до сих пор не хранит разрешения на доступ к файлам и являются ли это единственным способом? (Я никогда не делал хуков и скорее использую то, что является родным для Subversion.)

Answer 1

SVN имеет возможность хранить метаданные ( свойства ) вместе с файлом. Свойства в основном являются парами ключ / значение, однако есть некоторые специальные ключи, такие как svn: executetable. Если это свойство существует для файла, Subversion установит исполняемый бит файловой системы для этого файла при извлечении файла. Хотя я знаю, что это не совсем то, что вы ищете, этого может быть достаточно (было для меня).

Существуют и другие свойства для окончания строки (svn: eol-style) и типа mime (svn: mime-type).

Answer 2

Нет собственного способа хранения прав доступа к файлам в SVN.

Оба asvn и патч из этого поста блога, похоже, вышли (и размещены в официальном репозитории SVN), и это хорошо, но я не думаю, что у них будет такая обработка метаданных в основной версии в ближайшее время.

У SVN была возможность обрабатывать символические ссылки и исполняемые файлы специально в течение длительного времени, но ни одна из них не работает должным образом на Win32. Я бы не стал затаить дыхание на другую такую ​​непереносимую функцию (хотя ее было бы не слишком сложно реализовать поверх уже существующей системы метаданных).

Я хотел бы написать сценарий оболочки для ручной настройки прав доступа к файлу, а затем поместить его в хранилище.

Answer 3

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

Этот скрипт запускает вашу копию кодовой базы и устанавливает права на чтение для определенных файлов.

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

Answer 4

Так как это еще не было полностью сказано в предыдущих ответах. Но я ненавижу воскрешать зомбированные темы.

Поскольку добавление поддержки разрешений для SVN должно включать несколько ОС и типов разрешений, NFS, POSIX, ARWED и RACF

Это может сделать SVN раздутым, возможно конфликтовать с конфликтующими типами разрешений, такими как NFS и POSIX, или открыть возможные уязвимости эксплойтов / безопасности.

Есть несколько обходных путей. pre-commit, post-commit, start-commit - наиболее часто используемые и являются частью системы Subversion. Но позволит вам контролировать права доступа с любым языком программирования, который вам нравится.

Я реализовал систему, которую я называю упаковщиком, которая проверяет подтвержденные файлы рабочей копии, затем анализирует файл метаданных, в котором перечислены стандартные разрешения, требуемые для файлов / папок, и любые изменения в них, которые вы также желаете .

Owner, Group, Folders, Files
default: <user> www-user 750 640
/path/to/file: <user> non-www 770 770
/path/to/file2: <user> <user> 700 700

Вы также можете расширить это и разрешить такие вещи, как автоматическое перемещение, переименование их, пометка ревизий по типам, таким как альфа, бета, версия-кандидат, версия

Что касается поддержки клиентов для извлечения файлов репозитория с прикрепленными к ним разрешениями. Вам лучше заняться созданием установщика вашего пакета и предложением его в качестве ресурса.

Представьте, что люди устанавливают свои репозитории с исполняемым файлом, в котором установлены права root: www-user 4777

Answer 5

Многие ответы утверждают, что SVN не хранит права доступа к файлам. Это может быть правдой, но я смог решить файл DLL без проблем с разрешениями на выполнение, просто выполнив следующие действия:

1. chmod 755 badpermission.dll
2. mv badpermission.dll ../
3. svn update
4. svn rm badpermission.dll
5. svn commit badpermission.dll -m "Удалить dll, чтобы исправить разрешения"
6. mv ../badpermission.dll.
7. svn add badpermission.dll
8. svn commit badpermission.dll -m "Добавить dll обратно, чтобы исправить разрешения"
9. rm badpermission.dll
10. svn update
11. badpermission.dll возвращается с разрешениями на выполнение

Answer 6

Это является обновленной ссылкой для SVN-патча, которая корректно обрабатывает права доступа к файлам в стиле Unix. Я проверил на fedora12 и, кажется, работает как ожидалось:

Я просто сохранил его / usr / bin / asvn и использую asvn вместо команды svn, если мне нужно правильно обработать разрешения.

Answer 7

Я бы порекомендовал сгенерировать карту разрешений с помощью утилиты mtree (у FreeBSD она есть по умолчанию), сохранить карту в репозитории и, как было упомянуто выше, запустить скрипт, который восстановил бы правильные права доступа к файлам из карты как первый. шаг процесса сборки.

Answer 8

@ morechilli:

Оболочка asvn из моего предыдущего поста и блога в посте ОП, кажется, делает то, что вы предлагаете. Хотя он хранит разрешения в свойствах репозитория соответствующих файлов, в отличие от одного внешнего файла.

Answer 9

Мы создали пакетный файл, чтобы сделать это для нас. Предпочел бы фактическую поддержку в Subversion, хотя ...

Answer 10

Грэм, svn не хранит разрешения. Ваша единственная возможность - заключить вызов в svn в сценарий. Сценарий должен вызвать svn со своими аргументами, а затем установить права доступа. В зависимости от вашей среды вам может потребоваться вызвать ваш скрипт svn и настроить ваш PATH, чтобы убедиться, что он вызывается.

Мне очень нравится идея Morechilli, чтобы список файлов и разрешений был проверен в самом хранилище.