Моему приложению требуется доступ для чтения к /var/log/messages
, который принадлежит пользователю и группе root
. Какой минимальный уровень воздействия требуется на /var/log/messages
так что мое приложение может это прочитать?
В настоящее время я планирую изменить групповое владение /var/log/messages
в новую группу и добавить в нее пользователя root и моего приложения, но это также даст приложению права записи в /var/log/messages
.
ОС: Centos 5.5
Чтобы немного расширить приведенные выше ответы, вот пример использования в реальном мире. Я запускаю приложение для анализа корпоративных журналов Splunk на компьютере Redhat. Он работает под пользователем splunk и группой splunk. Это предотвращает доступ splunk к журналам в / 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/
Нет необходимости добавлять root в группу, так как она в любом случае будет иметь доступ через привилегии пользователя, просто дайте группе прочитать любую группу, которую вы выберете. Не забудьте также внести изменения с помощью logrotate, иначе изменения группы будут стираться каждую ночь.
Ваш план приемлем, и в «традиционной» схеме разрешений Unix это лучший вариант.
Другой вариант - настроить системный журнал для перенаправления интересующих сообщений в другой файл (что позволяет избежать предоставления пользователю приложения доступа ко всему конфиденциальному, что может быть /var/log/messages
).
Если вам не нравится традиционная схема разрешений User / Group / Other, вы также можете использовать ACL POSIX (другие, возможно, лучшие инструкции / информация, доступные через Google), чтобы предоставить пользователю вашего приложения доступ только для чтения к /var/log/messages
- это немного более детально и не рискует случайно поместить кого-то еще в группу приложения и дать ему доступ к вещам, которые они не должны видеть.
Yip я использовал setfacl
сделать это, чтобы дать доступ к mail.log
файл для клиента, вам также нужно будет вставить команду в logrotate.conf
файл, чтобы повторно установить ACL после ротации журналов, например:
postrotate
/usr/bin/setfacl -m o::r /var/log/mail.log
endscript
Обратите внимание: я только что настроил это и не тестировал, но, хотя он будет опубликован здесь, я не понимаю, почему это не сработает, кто-то поправит меня, если я ошибаюсь.
Ты можешь использовать ACL для этого. Он позволяет вам устанавливать определенные дополнительные правила доступа для определенных пользователей и файлов.
после того, как вы настроили свой ACL, как говорили другие люди, вместо того, чтобы помещать все свои правила acl в конфигурацию postrotate, вы можете переключить logrotate, чтобы использовать copytruncate вместо создания нового файла журнала каждый раз