У вас есть два дополнительных способа реализовать это:
Предоставление пользователям разрешений на gitудаленное использование репозиториев
Используется gitolite3для предоставления схемы репозиториев Hub-Live (это подробно описано здесь ), для которой в основном требуется наличие bareрепозитория (репозитория- концентратора ), позволяющего пользователям извлекать / извлекать и извлеченную версию того же репо. ( живой репо), расположенный на соответствующем пути, скажем /srv/www/html, например.
Мне нравится использовать gitolite3для управления репозитарием концентратор , но это не является обязательным требованием, хотя довольно удобно иметь детальный контроль доступа, привязанный к вашему выбору LDAP, если это необходимо. gitolite3может обеспечить детальный контроль вплоть до уровня филиала.
Также рекомендуется ограничивать возможности gitolite3пользователя с помощью sudoи обрабатывать перехваты с помощью sudoвызовов. Это рабочий пример использования gitolite3хуков (не стесняйтесь их адаптировать - или улучшать / исправлять - в соответствии с вашими потребностями):
Соответствующее содержание /etc/sudoersили /etc/sudoers.d/gitolite3будет что-то вроде:
Cmnd_Alias GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /usr/bin/xargs, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Cmnd_Alias GITOLITE_APACHE_CMDS = /usr/sbin/apachectl graceful
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3 ALL = (root)NOPASSWD: GITOLITE_CMDS
gitolite3 APACHE_HOSTS = (root)NOPASSWD: GITOLITE_APACHE_CMDS
Хаб Репо post-updateКрюк:
#!/bin/sh
echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"
sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"
exit 0
publisher-hub2live сценарий:
#!/bin/sh
echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"
cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master
# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info
exit 0
Ограничение возможности выполнения неавторизованных команд в оболочке входа
То, что вам нужно реализовать, - это воспроизводимый, проверяемый метод ограничения способности пользователя выполнять действия, отличные от строго разрешенных.
Это не обязательно, но это помогает, если ваши пользователи зарегистрированы в LDAP, и вы уже развернули механизмы для выполнения аутентификации LDAP, будь то с помощью модуля PAM или с помощью freeIPA и sssd.
Для реализации этого сценария в настоящее время я делаю следующее (имейте в виду, что для такого рода ограничений необходимо выполнение нескольких условий, в противном случае ограничение можно легко обойти):
- Пользователи не принадлежат к
wheelгруппе, единственной авторизованной для использования su(применяется через PAM). Обычно существует не-LDAP пользователь ( sysadm), который позволяет доверенным администраторам выполнять действия в случае аварийного восстановления или недоступности LDAP.
Пользователям предоставляется надлежащая защита rbashс доступной только для чтения переменной PATH, указывающей на частную ~/bin, этот ~/bin/каталог содержит ссылки на все разрешенные команды, например:
$ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud 7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud 8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 git -> /usr/bin/git*
lrwxrwxrwx. 1 root dawud 9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
что пользователи получают ограниченный, только для чтения окружающей среды (думаю такие вещи , как LESSSECURE, TMOUT, HISTFILEпеременных). Это делается для того, чтобы избежать shellпобегов из таких команд, как lessи обеспечить возможность аудита.
единственный разрешенный редактор - rvimпо той же причине. Пользователи могут только выполнять sudoedit, которые настроены для запуска rvimв sudoконфигурации:
Defaults editor=/usr/bin/rvim
если установлены ограничения MAC (в конкретном используемом дистрибутиве GNU / Linux включен SELinux), пользователи сопоставляются с пользователем SELinux staff_uи получают права на выполнение команд от имени другого пользователя в соответствии с требованиями sudo. Необходимо sudorulesразрешить тщательный анализ конкретной разрешенной версии, чтобы пользователь не смог обойти эти ограничения, а также может быть развернут в существующей инфраструктуре LDAP (это одна из функций freeIPA).
пользователи /home, /tmpи, возможно /var/tmp, полиинстанцируются через /etc/security/namespace.conf:
/tmp /tmp/.inst/tmp.inst-$USER- tmpdir:create root
/var/tmp /tmp/.inst/var-tmp.inst-$USER- tmpdir:create root
$HOME $HOME/$USER.inst/ tmpdir:create root
Полиинсталляция каталогов не является новой функцией, она доступна уже довольно давно. В качестве ссылки см. Эту статью с 2006 года . На самом деле, многие модули уже используют pam_namespaceпо умолчанию, но конфигурация по умолчанию в /etc/security/namespace.confне включает полианализацию. Также /etc/security/namespace.initследует сделать все скелетные файлы доступными только для чтения пользователям и принадлежать им root.
Таким образом, вы можете выбрать, могут ли пользователи выполнять какую-либо команду от своего имени (через ссылку в личном ~/binкаталоге, предоставляемую через /etc/skel, как описано выше), от имени другого пользователя (через sudo) или вообще без нее.
