Использование su с учетной записью службы для управления
Мы проходим трудный процесс настройки sudoers для минимальных привилегий. Мы обсуждали то, что требовалось на собрании, и наш менеджер порекомендовал вместо использования нашей собственной учетной записи с sudo мы su для управляемой службы. Мне это показалось немного странным и потенциально более сложным в применении. Я использую Linux всего несколько лет, а мой менеджер работает с Unix более 15 лет, поэтому я не собирался противоречить без некоторых исследований.
Я не нашел никакой литературы об этом способе работы, однако мой менеджер кое-что упомянул о проблемах с перезапуском служб и о том, что пользователь, вошедший в систему, затем владеет процессом. Мне интересно, является ли это пережитком времен, когда еще не существовало утилит управления услугами. Все, что мы используем, будет управляться systemd, поэтому я не ожидал, что это будет проблемой. Я также ожидал, что если бы возникла ситуация, когда команда должна быть запущена как учетная запись службы, это было бы сделано с помощью Runas_Alias .
В текущем контексте 2020 года допустимо ли использование su со служебными учетными записями вместо того, чтобы предоставлять доступ к нашим собственным учетным записям с помощью sudoers?
*** Дополнительная информация для разъяснения
Извините, если я не совсем понял. Службы будут запускаться с помощью диспетчера служб, такого как systemd. Это будет иметь учетную запись службы, указанную в файле модуля. Запуск sudo systemctl start запустит процесс под учетной записью, указанной в файле модуля.
Я ожидал, что лучший способ администрировать систему через ssh с минимальными привилегиями - это иметь команды, которые мне нужны для запустить от имени пользователя root, указанного с учетной записью my в sudoers. Редактирование файлов будет производиться с помощью sudoedit.
Мой менеджер, похоже, предлагал вместо добавления команд в файл sudoers с моим пользователем предоставить учетной записи службы весь необходимый доступ и использовать su для запуска в качестве службы. для выполнения этих задач.
Для меня это не имеет смысла. Похоже, что этим будет сложнее управлять, предоставить больше доступа к учетной записи службы, чем нужно, и сложнее контролировать.
Есть много причин для его предложения, одна из проблем, с которыми вы столкнетесь при запуске службы с вашей собственной учетной записью:
1- Служба, которая запускается учетной записью службы, загружается переменные среды этой учетной записи, зная, что большинству служб требуются эти переменные среды, они не будут доступны с использованием вашей учетной записи.
2- Когда вы запускаете службу со своей учетной записью, новые файлы, созданные этой службой, будут принадлежать ваш пользователь. Теперь представьте, что служба остановлена, и кто-то из ваших товарищей по команде пытается перезапустить ее, после запуска службы он попытается получить доступ к файлам, созданным недавно, но будет невозможно, что эти файлы принадлежат вашей учетной записи.
3- Другой сценарий: вы запускаете службу со своей учетной записью, и один из членов вашей команды пытается остановить / приостановить ее по какой-то причине, это будет невозможно также из-за отсутствия разрешений.