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

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

Если Вы не испытываете желание связываться традиционной схемой полномочий User/Group/Other, можно также использовать POSIX ACLs (другой, возможно лучшие практические руководства/информация, доступные через Google) для предоставления доступа только для чтения пользователя приложения к /var/log/messages - это является немного более мелкомодульным и не рискует случайно помещать кого-то еще в группу приложения и предоставлять им доступ к вещам, которые они не должны мочь видеть.

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

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

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

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

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

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

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

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

Это не будет сохраняться, так как логротат не будет повторно применять настройку ACL, поэтому для более постоянного решения я добавил правило для логротата для сброса 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/

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

Я бы проверил параметр «perm» для системного журнала -ng,если это программное обеспечение для регистрации, которое вы используете. Ссылка:https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.16/administration-guide/12

    file(
        "/var/log/messages"
        owner("root")
        group("root")
        perm(0644)
        );
    };

В противном случае вы можете добавить дополнительный файл журнала, например /var/log/apps/app1 _messages.log