по причине, которую я не совсем понимаю, все хотят sudo для всего и вся. На работе у нас даже записей столько же, сколько и способов прочитать файл журнала (head/tail/cat/more, ...).
Я думаю, что sudo здесь побеждает.
Я бы предпочел использовать сочетание каталогов setgid/setuid и добавлять ACL здесь и там, но мне действительно нужно знать, какие практики являются лучшими, прежде чем начинать.
На наших серверах есть %admin, %production, %dba, %users - т.е. много групп и много пользователей. Каждая служба (mysql, apache, ...) имеет свой собственный способ установки привилегий, но члены группы %production должны иметь возможность обращаться к файлу конфигурации или даже файлам журналов. Есть еще решение добавить их в нужные группы (mysql...) и установить хорошие разрешения. Но я не хочу изменять usermod всех пользователей, я не хочу изменять стандартные разрешения, так как они могут меняться после каждого обновления.
С другой стороны, настройку acls и/или смешивание setuid/setgid для каталогов я мог бы легко сделать, не «портя» стандартный дистрибутив.
Что Вы думаете об этом ?
На примере MySQL это будет выглядеть так:
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
Как вы думаете, это хорошая практика или мне определенно следует использовать usermod -G mysql и поиграться со стандартной системой разрешений?
Спасибо
решение1
Рекомендации: сохраняйте файл sudoers и используйте sudo.
На своей личной машине я предпочитаю setuid/gid, но я на своем компьютере один; и я не делаю этого с чем-то откровенно опасным, вроде rm.
решение2
Лучшие практики (и наиболее распространенные) склоняются к использованию sudo. Sudo предлагает вам детальный контроль, а конфигурация может обрабатывать несколько машин одновременно.
Использование ACL может дополнить это - sudoобрабатывает операции как root; ACL дает и забирает права на каталоги и файлы для пользователей и групп. Я бы не рассчитывал на то, что setgid и setuid сделают что-то разумное.
Я бы также реализовал группу wheel; это поможет повысить безопасность. Проверьте, suподдерживает ли ваша программа группу wheel.
Еще одно: если у вас есть viewили lessкак способ чтения файла журнала, то вы в группе риска: обе эти программы предлагают доступ к оболочке.
решение3
Мне кажется, что опция sudoers немного компактнее, чем setuid/setguid/ACL.
Без группировки пользователей ваш ACLS будет очень длинным. А если вы группируете пользователей, вы возвращаетесь к тому же месту, с которого начали.
Более серьезная проблема в том, что без какого-либо централизованного управления им контроль доступа распространяется по всей файловой системе. Конечно, вы можете легко обойти это с помощью макросов, шаблонов, управления конфигурацией и т. д. Но это совсем другой уровень, который никак не снижает сложность.
В моем небольшом магазине Drupal я довольно широко использую ACL для всех рабочих файлов, но sudo для всего доступа к управлению. Уровень управления конфигурацией, который я использую, — это Ansible, и приятно в нем то, что я могу легко шаблонизировать пользователей, их роли и, следовательно, какие группы они получают, на каких машинах и т. д. Sudoers управляется аналогичным образом. Мне это кажется довольно хорошей практикой, потому что это наиболее прозрачно.
Конечно, у меня, вероятно, не так много пользователей или групп, как у вас. Я мог бы представить себе размещение ACL в управлении конфигурациями. Но, хоть убей, я не вижу простого способа управлять многими машинами, многими пользователями и многими группами таким образом.