Какой самый безопасный способ разрешить пользователю доступ для чтения к файлу журнала?

Мое приложение требует доступа для чтения /var/log/messages, который принадлежит пользователю и группе root. Какой минимальный уровень воздействия требуется для того, /var/log/messagesчтобы мое приложение могло его прочитать?

В настоящее время мой план состоит в том, чтобы изменить владельца группы /var/log/messagesна новую группу и добавить в нее пользователя root и пользователя моего приложения, но это также даст привилегии записи приложения /var/log/messages.

ОС: Centos 5.5

Нет необходимости добавлять root в группу, так как в любом случае он будет иметь доступ через привилегированный пользователь, просто прочитайте группу для любой группы, которую вы решите. Не забудьте вносить изменения также с помощью logrotate, иначе групповые изменения будут стираться каждую ночь.

Просто чтобы немного расширить приведенные выше ответы, это реальный пример использования. Я запускаю приложение Splunk для анализа журналов предприятия на коробке Redhat. Он работает под пользователем Spunk и группой Spunk. Это предотвращает доступ спленков к журналам в / var / log, так как они доступны только пользователю root (или администратору sudo)

Чтобы разрешить доступ только для чтения только для splunk, я использовал некоторые ACL и модифицировал logrotate, чтобы сохранить его.

Вы можете вручную установить ACL с помощью

sudo setfacl -m g:splunk:rx /var/log/messages

Это не будет сохраняться, так как logrotate не будет повторно применять настройку ACL, поэтому для более постоянного решения я добавил правило logrotate для сброса ACL. Я добавил файл ..

/etc/logrotate.d/Splunk_ACLs

с

{
    postrotate
        /usr/bin/setfacl -m g:splunk:rx /var/log/cron
        /usr/bin/setfacl -m g:splunk:rx /var/log/maillog
        /usr/bin/setfacl -m g:splunk:rx /var/log/messages
        /usr/bin/setfacl -m g:splunk:rx /var/log/secure
        /usr/bin/setfacl -m g:splunk:rx /var/log/spooler
    endscript
}

Проверьте статус ACL файла с

$ getfacl /var/log/messages

Для получения дополнительной информации о ACL смотрите https://help.ubuntu.com/community/FilePermissionsACLs http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

Ваш план приемлем, и в «традиционной» схеме разрешений Unix это лучший путь.
Другой вариант - заставить системный журнал переадресовывать сообщения, представляющие интерес, в другой файл (что исключает предоставление пользователю приложения доступа ко всему, что может быть чувствительным /var/log/messages).

Если вы не чувствуете себя связанными традиционной схемой разрешений «Пользователь / Группа / Другое», вы также можете использовать списки управления доступом POSIX (другие, возможно, лучшие инструкции / сведения, доступные через Google), чтобы предоставить вашему приложению доступ только для чтения к /var/log/messages- это немного более детально и не рискует случайно поместить кого-то еще в группу приложения и дать им доступ к вещам, которые они не должны видеть.

Да, я использовал setfaclэто для предоставления доступа к mail.logфайлу для клиента, но вам также не нужно будет вставлять команду в logrotate.confфайл для переустановки ACL после ротации журналов, например:

postrotate
         /usr/bin/setfacl -m o::r /var/log/mail.log  
endscript

Заметьте, я только что настроил это и не проверял, но, хотя он будет публиковать здесь, не может понять, почему это не сработает, кто-то исправит меня, если я ошибаюсь.

Вы можете использовать ACL для этого. Это позволяет вам устанавливать определенные дополнительные правила доступа для определенных пользователей и файлов.

после того, как вы настроили свой ACL, как говорили другие люди, вместо того, чтобы поместить все ваши правила acl в конфигурацию postrotate, вы можете использовать logrotate, чтобы использовать copytruncate вместо того, чтобы каждый раз создавать новый файл журнала.