LINUX.ORG.RU

Git ограниченный доступ для юзеров

 


0

3

Здравствуйте!

Проблема кажется должна встречаться часто, но решения я так и не нашел.

Есть проект, есть несколько разработчиков. Как организовать совместную работу, чтобы у определенного разработчика был доступ (даже на чтение) только из определенных директорий проекта. Т.е. пусть структура будет такая:

  • bin // папка с компилированными бинарниками (компилируется CI из master ветки или еще как)
  • lib // то же но для динамических библиотек
  • src // папка с исходными файлами всего проекта
    • App1 // папка из кот компилиться приложение 1
    • App2 // то же 2
    • Class1 // папка содержит реализацию класса1 (кот может использоваться при сборке App1 и др.)
    • Class2 // то же 2
  • include // папка содержит ссылки на заголовочные файлы классов, приложений App и пр. из директории src
  • obj // папка с всеми объектными файлами

Хочется выдать user1 права на чтение из папок bin, lib, include, obj. И временно выдать права на чтение-модификация src/Class1 и чтобы другие папки из src он не смог прочесть. Так как у него будут obj файлы он сможет пересобирать приложения со своими наработками в Class1, тестить и т.д. Так можно пустить временно разработчика в проект, при этом не выдавая ему все исходники.

Хочется систему которая сможет управлять выдачей/изменением таких прав для конкретного пользователя.

Систему рассматриваем git или mercurial. В gitolite нашел что можно выдать права на отдельный путь. Но нам не подходит, так как нельзя использовать ssh (и возможно даже с ним не получится такое реализовать).

За любые мысли и советы буду благодарен.


bin // папка с компилированными бинарниками (компилируется CI из master ветки или еще как) lib // то же но для динамических библиотек

O_o

Обычно в git хранят исходные файлы. Нельзя опубливать бинарники отдельно?

avsej
()
Ответ на: комментарий от avsej

Вполне можно, но проблему закрытия доступа ко всем исходникам из папки src это не решает

aspera
() автор топика

git такого не может по определению - ты не сможешь посчитать хеш working copy, если у тебя нет доступа к части репозитория.
Делай по репозиторию на каждую сущность, правами на которую нужно управлять независимо. И да, git не предназначен для хранения бинарников.

maloi ★★★★★
()

Никак. Без возможности читать весь репозиторий никакие DVCS работать не будут. Ограничения на запись и ssh также несовместимы. Можете делать индивидуальные клоны репозитория для каждого разработчика и вычищать оттуда всё что он не должен видеть, а потом трахаться с вливанием в основной репозиторий изменений. Похоже вы в разработке вообще ничего не понимаете, если у вас такие требования возникли и к тому же вы храните в репозитории бинарники - постарайтесь осознать это и настройте нормальный репозиторий с полным r/w доступом (но запретом forced push, разумеется) или найдите того кто это за вас сделает, иначе с вашим втыканием палок в колёса разработчикам вы свой сверхценный проект, где не дай бог кто увидит лишнюю строчку кода, просто загубите.

slovazap ★★★★★
()
Ответ на: комментарий от maloi

Спасибо, так и буду делать по репозиторию. А чем плохо хранить бинарники? иначе придется их сливать по другому протоколу (ftp, smb, http или др.), а тут как бы единообразие.

aspera
() автор топика
Ответ на: комментарий от slovazap

Вы правы, я в разработке не разбираюсь - поэтому и такие вопросы. Про втыкание палок - пока ищу методы, опыт и способы реализовать это безболезнено.

aspera
() автор топика
Ответ на: комментарий от aspera

плохо тем, что в любом репозитории хранятся все версии всех файлов, а т.к. при обычно при пересборке меняются все файлы - репозиторий будет расти очень быстро.
Моё мнение насчет предоставления объектных файлов - делайте нормальную плагинную архитектуру с динамической подгрузкой библиотек, иначе не взлетит. А если сделаете плагинную архитектуру - не нужно будет предоставлять объектники, можно будет сразу бинарник. Но я конечно не настоящий сварщик, так что могу быть неправ.

maloi ★★★★★
()
Ответ на: комментарий от aspera

буду делать по репозиторию

Тогда гугли про подмодули.

А чем плохо хранить бинарники?

Как минимум тем, что Git хранит изменения файлов, с бинарниками у тебя каждая незначительная правка в бинарнике = полная копия бинарника в гите, так что будет много места жрать. Да и вообще в этом нет смысла - ты можешь взять код из Git'а и собрать нужный бинарь.

alozovskoy ★★★★★
()
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от maloi

Да, в динамическую библиотеку нужно собирать более крупные сущности (не один малый класс) и на них делать отдельный репозиторий со всеми нужными правами. Будем смотреть в эту сторону.

Спасибо, еще раз.

aspera
() автор топика
Ответ на: комментарий от alozovskoy

Смотрел про submodules и про subtree, пока до конца не разобрался, но вижу что это не совсем то.

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

aspera
() автор топика
Ответ на: комментарий от maloi

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

Ещё одна причина в том, что Вася на своём компе собирает эти бинарники под одну архитектуру, а Петя на своём собирает под другую — и какую из них пихать в репозиторий? — никакую.

gentoo_root ★★★★★
()

Как уже тут сказали, DVCS не дружат с разграничением прав доступа для пользователей. Но, если DVCS не принципиально, то Svn разграничивать права на уровне веток в репозитории умеет. Сам это дело использовал.

На счет хранения бинарников под VCS. Это религиозный вопрос и большинство из тех, кто кричат, что так нельзя, на поверку оказываются красноглазыми фанатиками. Тут нужно своей головой думать и если такое нужно, то вполне можно. Был опыт: релизные версии бинарников мы фиксировали в специальных ветках репозитория, откуда их забирали внедренцы для установки «в бой». Правда, у нас была всего одна целевая платформа, но схема работала: все следы оставались в логе репозитория, всегда можно было поднять конкретную версию, не опасаясь, что где-то что-то подменили или забыли удалить.

eao197 ★★★★★
()

Гит для бинарей — это жопа.

olibjerd ★★★★★
()
Ответ на: комментарий от gentoo_root

какую из них пихать в репозиторий?

если уж захотеть, то можно бранчи начать использовать.

maloi ★★★★★
()
Ответ на: комментарий от eao197

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

тут говорят не про абстрактную VCS, а про конкретную DVCS, в которой нельзя.

maloi ★★★★★
()
Ответ на: комментарий от maloi

тут говорят не про абстрактную VCS, а про конкретную DVCS, в которой нельзя.

Что-то в Git/Mercurial принципиально мешает помещать под version control бинарные файлы?

А если эти бинарные файлы — это не exe/dll/so, а необходимые приложению ресурсы вроде .ico/png/wav файлы?

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

релизные версии бинарников мы фиксировали в специальных ветках репозитория, откуда их забирали внедренцы для установки «в бой»

git tag отменили?

thriller ★★
()
Ответ на: комментарий от thriller

Это было еще до рождения git-а на свет.

С git tag-ом были бы те же яйца, только в профиль.

Так что на счет отмены или неотмены git tag-а расскажите тем, кто думает, что в git-е бинарники фиксировать нельзя-нельзя.

eao197 ★★★★★
()

Если действительно нужен такой подход, можно что-то похожее сделать через submodule.

orm-i-auga ★★★★★
()

Разбей на подпроекты.

За бинари в репозитории надо пинать по причинному месту, до просвещения...

То чего ты хочешь, позволяет svn, раз у вас такой флоу, что приходиться иметь секреты от других членов команды, но при этом вы не в состоянии разбить сиё на логичные подпроекты, то кушайте кактус используйте svn.

pon4ik ★★★★★
()
Ответ на: комментарий от aspera

А чем плохо хранить бинарники?

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

andreyu ★★★★★
()

Это противоречит принципам открытой модели разработки.

Если не секрет - чем вызвана необходимость такого разделения?

Ведь эти все барьеры можно легко обойти. В простейшем случае: декораторы, LD_PRELOAD, strace, gdb...

Будет правильным упомянуть еще другие способы обхода.

*nix-ах сложно что-либо утаить. Открытость системы заложена уже на архитектурном уровне.

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

Проблемы доверительности и разграничения доступа решаются криптографическими методами.

Наконец делаются открытыми API, интерфейсы. Они по определению открыты.

anonymous
()
Ответ на: комментарий от eao197

Что-то в Git/Mercurial принципиально мешает помещать под version control бинарные файлы?

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

maloi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.