Лучший способ сделать это — использовать функцию 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
(помните немного о том, что веб-сервер может читать все файлы)
Во-первых, документация 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 по мере необходимости.