Git меняет umask по умолчанию при обновлении файла

Быстрый ответ: эта функция оболочки должна быть помещена в ваш файл ~/.profile. Далее следует объяснение.

git(){(umask 0022; command git "$@")}

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

Git не имеет опции конфигурации для установки umask, он не меняет свою umask после выполнения. Вы должны установить umask Git извне, пусть он будет унаследован от родительского процесса (обычно оболочки).

Ммм, похоже, тебе не нравится идея, что что-то кроме git изменило umask. Итак, давайте изменим его только при выполнении git.

Когда оболочка выполняет строку, она берет первое слово в строке и пытается найти функцию с таким именем. Только если его нет, он пытается найти команду с таким именем в PATH. Функция, которую я написал выше, называется git, поэтому любой прямой вызов git теперь выполняет ее вместо команды git.

Функция выполняет подоболочку, изменяет ее umask и выполняет команду git внутри подоболочки. После того, как Git завершит свою работу, подоболочка также завершит работу, и исходный экземпляр оболочки по-прежнему будет иметь исходную маску umask.

Однако функция также показывает, как обойти себя. Если вы вызываете git через command git или даже /usr/bin/git, функция вызываться не будет. Однако для любого приличного использования этого вполне достаточно.

Разрешать выполнение файла в виде двоичного файла довольно опасно. Во всяком случае, я решил проблему с umask. Мой post-receive скрипт выглядит так:

!/bin/sh
umask 002
GIT_WORK_TREE=/var/www/site git checkout -f

Итак, file permissions установлено в 664, а directory permissions установлено в 775, что меня вполне устраивает.

P.S. Установка umask в файле .profile пользователя git не имеет никакого эффекта, и я не понимаю, почему, пожалуйста, прокомментируйте, если вы знаете, почему это происходит.

Я только что столкнулся с этой проблемой при проверке репозитория в домашнем каталоге, смонтированном через NFS на Ubuntu 14.04 (Trusty) с использованием ядра Linux Xenial версии 4.x с бэкпортом. Git clone в локальный каталог был в порядке. Еще более странно: второй сервер Ubuntu 14.04 не обнаружил такой же проблемы в том же смонтированном каталоге.

После долгих поисков я смог увидеть, используя strace, что git вызывает системный вызов open() для создания каждого файла с параметрами O_CREAT, O_WRONLY и O_EXCL и режимом 0666, но затем следующий системный вызов был fstat() против файл и сказал мне, что это режим 0700. В моем случае проблема затронула только определенные файлы в репозитории. Несмотря на то, что git ls-index показывает режим 0644 для большинства файлов, некоторые из них создавались правильно, а другие нет; хотя это всегда были одни и те же файлы с неправильными разрешениями на клон.

Я заметил разницу в версии ядра между двумя системами, а затем обнаружил следующую ошибку: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1654288

Обновление ядра до 4.4.0-98 (с 4.4.0-59) исправило это для меня. Я проверил некоторые хосты, все еще использующие ядро ​​​​Linux версии 3.x, и у них не было проблем.

Использование хуков для изменения режима файла после проверки устраняет проблему после того, как она уже возникла. У вас уже есть плохой файловый режим в файловой системе при выполнении хука. Если запрос поступает как раз между проверкой и выполнением хука, сервер ответит ошибкой 500. Но вас все равно может заинтересовать это решение.

Вам нужен post-checkout хук, запускающий chmod g-w все необходимые файлы. Хук .git/hooks/post-checkout должен быть исполняемым и получает текущий HEAD в качестве второго параметра ($2 в оболочке). Крючок может выглядеть так:

#!/bin/bash
git ls-files -z --with-tree="$2" | xargs -0 chmod g-w --

Поскольку хук не получает список проверенных файлов, это может быть наилучшей возможной реализацией. Он изменяет режим всех файлов в текущем HEAD.