Существуют ли какие-либо потенциальные подводные камни при изменении прав доступа к файлам конфигурации в каталоге /etc для пользователя, не являющегося пользователем root?

Существуют ли какие-либо потенциальные подводные камни при изменении прав доступа к файлам конфигурации в каталоге /etc для пользователя, не являющегося пользователем root?

На наших машинах запущены различные службы, например, cassandra, datadog и т. д.

Иногда нам необходимо изменить конфигурацию, и мы хотим автоматизировать распространение файлов конфигурации и перезапуски.

Мы используем Jenkins для автоматизации рабочего процесса для нашего прикладного программного обеспечения и думали использовать его также для сервисов. Мы не хотим, чтобы сервер, на котором работает Jenkins, имел удаленный root-доступ (или даже sudo) к хост-серверу.

Мне было интересно, можем ли мы безопасно изменить владельца /etc/cassandra на cassandra, /etc/datadog на dd-agent и т. д., потому что это помогло бы нам автоматизировать. (На самом деле, рекомендуется ли, чтобы такие папки/файлыдолженпринадлежать соответствующему пользователю, и что наличие root в качестве владельца неправильно?)

решение1

Идея этого каталога заключалась в том, что /etcкаталог содержит всеобщесистемныйконфигурация - в отличие от конфигурации каждого отдельного пользователя, которая в большинстве случаев находится $HOME/.configгде-то ниже. Поскольку общесистемная конфигурация влияет на всех пользователей, то правильно, что эти файлы принадлежат root.

Теперь, я не знаю вашей системы, но вы, вероятно, запускаете cassandra и т. д. один раз на систему, и поэтому у вас, вероятно, нет необходимости в индивидуальном файле конфигурации пользователя. Я не вижу никаких подводных камней в изменении владельца этих файлов / подкаталогов, за исключением того, что это противоречит тому, как это было спроектировано. (Если только вы не измените владельца основного /etcкаталога!)

Лично я бы создал каталог экземпляра (вероятно, в его домашней папке) и использовал бы конфигурацию, хранящуюся там, но это уже на ваше усмотрение.

решение2

Root не должен быть владельцем файлов конфигурации etc, относящихся к приложениям. Элегантное решение было бы примерно таким: приложение datadog запускается пользователем datadog, а файлы конфигурации принадлежат datadog и группе datadog. Но теперь появляется jenkins, и ему нужно посмотреть/отредактировать некоторые файлы в /etc/datadog, но, возможно, не все.

Итак, мы создаем новую группу под названием "datadogjenkins" и делаем ОБА datadog и jenkins членами этой группы. Затем мы меняем ownerGROUP для файлов/папок, которые jenkins должен читать/писать/выполнять, на нашу новую группу.

Теперь и datadog, и jenkins могут получить доступ к этим ресурсам. И ни одному из них не нужно повышать привилегии до root. И мы можем не допускать jenkins к тому, что ему не нужно видеть, на случай, если jenkins будет скомпрометирован.

Надеюсь, я достаточно хорошо объяснил.

Связанный контент