Как мы могли позволить некорневым пользователям управлять system.d сервисом?
Существует в основном две вещи к этому:
1) полномочия на файлах и каталог, которые уже существуют:
Ответ Alan главным образом касается этого: создайте специальную группу, к которой Вы добавляете всех пользователей, которые, возможно, должны были бы записать файлы. Удостоверьтесь, что каталог, где Вы загружаете, самостоятельно перезаписываем для той группы: chmod 0775 path/to/the/directory. Любым существующим файлам будет нужно chmod 0664.
"Волшебные" числа являются восьмеричными и обозначают триплеты: setuid, полномочия владельца, полномочия группы, мировые полномочия. setuid является не представляющим интерес для Вас, сохраните его 0. для других восьмеричное число (0-7) говорит Вам полномочия: если 0th укусил, идет, файл/каталог является исполняемым файлом (для каталога, это означает, что он может быть введен), если 1-й бит находится на нем, является записываемым, 2-й бит управляет удобочитаемостью - например. 0754 означал бы, что у владельца есть все полномочия, элементы группы могут читать и выполниться, и остальная часть мира может только считать его. Можно записать то же с мнемоникой как это: chmod u=rwx,g=rx,o=r. Посмотрите man chmod система Linux для подробно объяснения.
2) полномочия на недавно созданных файлах:
Искать umask установка в том, что делает загрузку. Это говорит, с какими полномочиями создаются новые файлы. Снова посмотрите man umask в системе Linux/UNIX идея, что безотносительно битов Вы начинаетесь umask (та же нотация что касается chmod объясненный выше), исключены из полномочий на недавно созданные файлы - например, если Вы устанавливаете Ваш umask кому: 0023, Ваши файлы будут созданы со всеми полномочиями для Вас, не записываемый для Вашей группы по умолчанию и не записываемые никакой исполняемый файл кем-либо еще. Это - обычно плохая идея установить бит 0th здесь, с тех пор на создании каталога это делает это неисполняемым файлом, какие блоки, вводящие каталог вообще (для группы пользователей, для которых бит установлен, в 0023 пример для "кого-либо еще").
В дополнение к этому могло бы стоить присвоить ACLs по умолчанию каталогу, если базовая файловая система поддерживает их. Это позволило бы более прекрасное гранулярное управление доступом (ACL обозначает Список управления доступом, подобный Windows один). Посмотрите man setfacl для получения дополнительной информации.
БОЛЬШОЕ ПРЕДУПРЕЖДЕНИЕ: это не хорошая идея мировым перезаписываемым make-файлам! Сохраните права в минимуме, который работает.
Просто добавьте все необходимые команды на Sudoers Раздельно:
%webteam cms051=/usr/bin/systemctl restart httpd.service
%webteam cms051=/usr/bin/systemctl stop httpd.service
%webteam cms051=/usr/bin/systemctl start httpd.service
%webteam cms051=/usr/bin/systemctl status httpd.service
Самое безопасное для их размещения, как jofel .
Если бы я хотел позволить кому-то использовать ограниченное подмножество способностей команды, я бы не доверял подстановочным картам в строке Sudoers, чтобы сделать это. Даже если язык был более выразительным, чем раковины, там слишком много угловых случаев, чтобы отслеживать.
Сервис « SERVICE HTTPD * « Безопасен относительно Безопасен, потому что (проверьте это :) Услуги имеет только один полезный флаг ( - Состояние - все ), который не делает ничего особенно чувствительного, а (проверьте это тоже :) /etc/init.d/httpd будет принимать только командные строки, которые вы хотите разрешить.
Если есть так много комбинаций, которые их выпускают, становится неловким, вы, вероятно, возмещаете вопрос, что вы делаете. Но вы могли бы дать им доступ к тщательно написанному вспомогательному скрипту, который запускает команду для них (очень похоже на /etc/init.d/http ). Даже в этом случае вы должны быть такими же точными и явными, насколько это возможно, чтобы точно выделить, какие команды и параметры разрешены, и не передавайте пользовательский ввод непосредственно к целевой команде.
Создайте псевдоним команды с командами, к которым вы хотите, чтобы они имели доступ. Затем назначьте группу на этот псевдоним:
Cmnd_Alias APACHE-SVC = /usr/bin/systemctl stop httpd, /usr/bin/systemctl start httpd, /usr/bin/systemctl restart httpd
%webteam ALL=APACHE-SVC
Также хорошей практикой является размещение любых правок в файле /etc/sudoers.d/filename, а не прямое редактирование файла sudoers. Обязательно укажите на ваш .d/filename в sudoers, что большинство новых дистрибутивов делают в любом случае. Размещение этих двух строк в sudoers должно помочь:
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
Примечание: # перед includedir не является комментарием. Он должен остаться.
Ответ @jofel был именно тем, что мне нужно, чтобы получить рабочую настройку. Предлагаю это для тех, кто еще столкнется с этим вопросом. Мне нужен был способ заставить capistrano перезапустить мое Ruby-приложение после развертывания с моей локальной машины. Это означает, что мне нужен был беспарольный доступ к перезапуску systemd служб. Вот что у меня есть, и это работает замечательно!
Примечание: мой пользователь и группа называются deployer
Поместите код в пользовательский файл здесь: /etc/sudoers.d/deployer
Код:
%deployer ALL= NOPASSWD: /bin/systemctl start my_app
%deployer ALL= NOPASSWD: /bin/systemctl stop my_app
%deployer ALL= NOPASSWD: /bin/systemctl restart my_app