LINUX.ORG.RU
решено ФорумAdmin

Operation not permitted в git hooks.

 


0

1

Не получается корректно настроить работу post-receive.

После выполнения push, не удается выполнить chmod / chown.

remote: chown: changing ownership of '/home/site/test': Operation not permitted

Команда в hooks/post-receive:

chown -R username:nginx /home/site/test

На файл пытался выставить права root:root с suid флагом, но все-равно пишет Operation not permitted

И еще не совсем понятно, на какие каталоги какие права должны быть выставлены.

Т.е. сейчас на директорию test и её содержимое выставляются следующие права:

chown -R username:nginx /home/site/test

find /home/site/test -type f -exec chmod 644 {} \;

find /home/site/test -type d -exec chmod 755 {} \;

Но я не совсем уверен, что это корректно.

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

Но я могу и ошибаться.

Работа с git-репозиторием осуществляется с помощью SSH.

GIT_SSH_COMMAND=«ssh -i ~/ssh_keys/private» git clone «username@[2a01:4f8:xx:xx::xx]»:/~/test.git

Репозиторий находится в директории /home/repository/test.git

Домашний каталог пользователя /home/repository

Итого:

1. Почему не работает post-receive и как сделать правильно.

2. После команды git --work-tree права на файлы в директории /home/site/test будут принадлежать тому пользователю, из под которого происходит push на сервер?

А группа? Если пользователь состоит только в группе nginx, значит и группа будет nginx?

3. Если в предыдущем вопросе пользователь/группа в /home/site/test равны username:nginx, то смысла в chown в post-receive нет? Но тогда как быть с chmod? Ведь он тоже не выполняется.

4. Ни chmod, ни chown нет при выставлении пользователю username shell-а git-shell. Как в таком случае выполнять команды в post-receive, если данных команд нет при использовании git-shell.

5. Корректно ли сейчас выставляются права на каталоги/файлы.

6. Может где можно почитать обо всем этом более развернуто?

От ссылки не отказался бы (не на поисковик).

На git-scm.com уже был, но на тему прав там инфы не нашел.


Я не осилил понять пост (какая-то страшная лапша). На скажу вот что:

  1. при оперировании git через ssh (не используя сторонних трекеров типа GitLab) операции производятся из-под пользователя, под которым ssh логинится.
  2. chown фактически может сделать только root. Т.е. если логин по ssh под обычным пользователем — chown не пройдет (ssh доступ для root — очень плохо, не делай так!)
  3. chmod может делать только владалец файла и root.
KennyMinigun ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Ммм... Вроде старался написать более-менее понятно. Но похоже не удалось...

1. Ммм, в принципе так и предполагал...

2. У меня с гитом только обычный пользователь работает по ssh.

3. Ммм... Ну без chown / chmod в post-receive файлы в test директорию заливаются с пользователем username и группой nogroup.

Корректно ли это? При этом у директорий группа nginx, а у файлов nogroup.

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

На файл пытался выставить права root:root с suid флагом

Если я правильно понял, ты пытался на скрипт post-receive поставить suid. Однако на скриптах suid не работает (по крайней мере в линуксе) — это такая мера безопасности.

При этом у директорий группа nginx, а у файлов nogroup.

Это уже зависит как Git будет изменять/создавать файлы. Если только будет изменять — то владелец останется, а права выставятся как записано в Git (да, Git трекает права файлов тоже). Если создает — то очевидно владельцом будет username:nogroup.

Однако не знаю, как поступает Git когда требуется изменить файл. А конкретно: пересоздает ли Git его в таком случае. Касательно директорий все проще: git не имеет понятия о директориях, по этому их не трогает (если только не требуется создать директорию для того, чтоб поместитть туда файл).

Короче, если ты хочешь делать chmod/chown то настрой может sudo (для того, чтоб например username мог запускать sudo chown -R nginx:nginx /home/site/test без ввода пароля)

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

сли я правильно понял, ты пытался на скрипт post-receive поставить suid. Однако на скриптах suid не работает (по крайней мере в линуксе) — это такая мера безопасности.

Ок, понял.

Короче, если ты хочешь делать chmod/chown то настрой может sudo (для того, чтоб например username мог запускать sudo chown -R nginx:nginx /home/site/test без ввода пароля)

Ммм... А на сколько это адекватное решение вопроса?

Не окажется ли так, что применение sudo в post-receive может привести к каким-либо негативным последствиям в дальнейшем?

А вообще если при работе с git-ом права будут нормально выставляться на файлы / директории, тогда можно в принципе обойтись и без chown / chmod.

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

Ммм... А на сколько это адекватное решение вопроса?

Настрой sudo как можно более ограничено. Я не сейчас не сильно помню что конкретно в sudo можно ограничить, почечитай ман.

Однако я 100% уверен, что можно настроить чтоб без ввода пароля можно было запустить только и исключительно

sudo chown -R nginx:nginx /home/site/test

Скорее всего ничего страшного не случится, если кто-то там еще раз сменит владельца внутри /home/site/test на nginx (то же саме с правами).

Не окажется ли так, что применение sudo в post-receive может привести к каким-либо негативным последствиям в дальнейшем?

Ну, если скрипт post-receive окажется на другом сервере с ненастроенным sudo то будет проблема.

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