Ошибка разрешения при создании резервной копии при установке gitlab omnibus

Лучший способ сделать это — использовать функцию chroot sshd и подсистему sftp.

Учитывая настройку DocumentRoot в /var/www-sites/example.com/html

Создайте группу с именем вроде "chrootwebusers"

root@hostname:~ # addgroup chrootwebusers

Добавьте пользователя и задайте его домашний каталог и некоторые другие параметры -

useradd -g chrootwebusers -d /var/www-sites/example.com -s /bin/false theusername
mkdir -p /var/www-sites/example.com/html
chown theusername.www-data /var/www-sites/example.com
chmod -R 750 /var/www-sites/example.com
chmod g+s /var/www-sites/example.com
passwd theusername

Это добавит пользователя с именем theusername с членством в группе в вашу группу chrootwebusers с домашний каталог /var/www-sites/example.com и доступ для чтения/записи ко всему, что находится под ним.

chmod g+s /var/www-sites/example.com работает с группой www-data, являющейся группой-владельцем. Использование бита setgid в каталоге приводит к тому, что любые новые файлы/каталоги, созданные внутри него, сохраняют ту же групповую принадлежность, что и каталог example.com. Это означает, что пользователь, от имени которого запускается веб-сервер, всегда сможет прочитать файлы полностью (помните об этом! )

Затем отредактируйте /etc/ssh/ssdh_config.Уточните строку, указывающую подсистему sftp, и закомментируйте ее:

#Subsystem sftp /usr/lib/openssh/sftp-server

И добавьте ссылку на подсистему sftp internal-to-sshd

Subsystem sftp internal-sftp

Наконец, внизу файла добавьте

Match Group chrootwebusers
    ChrootDirectory /var/www-sites
    ForceCommand internal-sftp -u 0027

Итак... как это все работает? Подсистема sshd internal-sftp ожидает входа в систему от кого-то, кто является членом группы chrootwebusers. Когда это произойдет, он выполнит их chroot, чтобы то, что вы видите как /var/www-sites, они видели как / . Они смогут видеть каталог example.com, переходить в него и читать/записывать файлы как там, так и в DocumentRoot /var/www-sites/example.com/html — но они увидят все это как /example.com/html. Параметр -u 0027 устанавливает umask таким образом, что любые новые создаваемые файлы/каталоги будут иметь разрешения 640/750, а трюк setgid, который мы использовали ранее, сделает пользователя-владельца theusername и группа-владелец пользователя www-data (помните немного о том, что веб-сервер может читать все файлы)

0
05.01.2017, 19:18
1 ответ

Во-первых, документация gitlab, похоже, считает, что вы должны запускать эту команду с помощью sudo:

https://github.com/gitlabhq/gitlabhq/ blob / 7-10-stable / doc / raketasks / backup_restore.md

На основе кода:

https://github.com/gitlabhq/gitlabhq/blob/7-10-stable/lib/backup/ manager.rb

Похоже, он запускает chmod 700 в 3 каталогах (репозитории, база данных, загрузка) (и не работает в базе данных) в каталоге резервных копий вашей конфигурации (Gitlab.config.backup.path). Согласно документации, эта переменная Gitlab.config.backup.path извлекается из config / gitlab.yml. Если вы не можете найти этот файл конфигурации, вы можете временно добавить строку выше /opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:19, чтобы распечатать каталог резервной копии:

puts("Backup dir is: #{Gitlab.config.backup.path}")

Вы также можете вместо этого можно получить ту же информацию, используя команду strace:

$ strace -f gitlab-rake gitlab:backup:create 2>&1 | grep "^chdir\|^fchdir"

Как только вы найдете каталог резервных копий, посмотрите на каталог db внутри него. Следует применять стандартные разрешения Linux для устранения неполадок. От какого пользователя вы запускаете команду и какой набор разрешений имеет каталог? Sudo chmod / chown по мере необходимости.

3
28.01.2020, 02:26

Теги

Похожие вопросы