[Devel] git.office

[Evgeny Sinelnikov]

4 июля 2009 г. 20:11 пользователь Vitaly Lipatov (lav на etersoft.ru) написал:
> В сообщении от Четверг 25 июня 2009 Evgeny Sinelnikov написал(a):
> ...
>> Среди задач, связанных со вторым сервером, есть задачипроблема
>> предоставления "публичного" доступа для разработчиков. Задача
>> противоречивая. Не вижу особого смысла в ней, если сервер публично
>> доступен. Исходники становятся постоянно скомпрометированы. Поэтому я
>> не стремился открывать на git.office.etersoft.ru http:// и git://
>> протоколы.
> OK.
>
>> Есть некоторая примитивная защита проверки по ip, но мне кажется, что
>> это не правильно. Такой сервер либо должен быть доступен из-вне, как
>> сейчас, и публичные протоколы для него недопустимы, либо недоступен
> У нас есть схема аутентификации в апаче по общему логину/паролю (к
> @etersoft.ru), построенная на mysql. Я её включаю за минуту, обращайтесь.
>

С точки зрения безопасности этот вариант приемлем только при
использовании https. Иначе это дыра. Вопрос в том насколько важно
недопустить утечку из git.office. Если это не так уж важно, то можно и
сделать... Если важно, но нужно использовать https, а это для обмена
исходниками не так удобно - придётся указывать пароль.

https я пока не пробовал, так что точно не могу сказать как он работает.

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

> ...
>> Так вот. Столкнулся я с этим вопросом с след. задаче. Решил хранить
>> изменения сайта в git и, по мере тестирования, заливать их к себе на
>> git.office. После отладки предполагал делать на хостинге git pull.
> Зачем исходники сайта хранить в закрытом git?
>

Хм... Ну, затем, чтобы не хранить в открытом :)
Пока я обошёлся каталогом private, как и описывал...


>>
>> Не удобство оказалось в том, что для доступа к git.office обязательно
>> нужны ключи, а хранить их на хостинге не хочется.
> Для этого все пользуются ssh-agent и форвардом агента при заходе на удалённые
> хосты. В мане это называется "forwarding of the authentication agent
> connection."
> А ключи все хранят у себя на машине.
>

ух ты... я такое пока не использовал... Локально - да, а форвардинг я
эмулировал вот так:.

$ cat /home/sin/.bash_profile
...
/etc/X11/profile.d/ssh-agent.sh &&
SSH_AGENT_PID=`pgrep ssh-agent -u sin|head -1 2>&1` &&
SSH_AUTH_SOCK=/home/sin/.ssh/agent &&
export SSH_AGENT_PID &&
export SSH_AUTH_SOCK

>> PS: не гибкая схема распределения прав является вообще проблемным
>> вопросом, как и права на файловых системах в unix, имеющих
>> существенные проблемы при групповой работе.
> Связи с темой распределения прав пока не заметил.

Что тут непонятного ? :)
Неудобно в Unix группы использовать для совместного доступа...

Вот яркий пример:
 - делаем группу staff
 - даём права на каталог 775 и эту группу назначаем
 - создаём в этом каталоге файл с правами 664 одним пользователем
 - пытаемся с ним работать другим пользователем: править, удалять
каталог можем, перезаписать, из-под mc, другим файлом не можем... И
чего только не можем - этого не можем, того не можем :) Те же права
сменить не можем и возможности дать такое право стандартными путями
нет. Ну костыли suid'ные только и помогают.
 - оба пользователя в группе staff, если что...

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

-- 
Sin (Sinelnikov Evgeny)