Solución 1:
Solo para ampliar un poco las respuestas anteriores, aquí hay un caso de uso real. Ejecuto la aplicación de análisis de registros empresariales Splunk en una caja Redhat. Se ejecuta bajo el usuario splunk y el grupo splunk. Esto evita que Splunk acceda a los registros en /var/log, ya que solo son accesibles para root (o un administrador de sudo)
Para permitir el acceso de solo lectura solo para splunk, he usado algunas ACL y modifiqué logrotate para conservarlo.
Puede configurar manualmente la ACL con
sudo setfacl -m g:splunk:rx /var/log/messages
Esto no persistirá ya que logrotate no volverá a aplicar la configuración de ACL, por lo que para una solución más permanente, agregué una regla a logrotate para restablecer la ACL. Agregué el archivo.
/etc/logrotate.d/Splunk_ACLs
con
{
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
}
Verifique el estado de ACL de un archivo con
$ getfacl /var/log/messages
Para obtener más información sobre ACL, consulte https://help.ubuntu.com/community/FilePermissionsACLshttp://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/
Solución 2:
No es necesario agregar root al grupo, ya que tendrá acceso a través de los privilegios de usuario de todos modos, solo lea el grupo al grupo que decida. Recuerde realizar los cambios con logrotate también o los cambios de grupo se borrarán todas las noches.
Solución 3:
Su plan es aceptable y en el esquema de permisos "tradicional" de Unix es el mejor camino a seguir.
Otra opción es hacer que syslog desvíe los mensajes de interés a otro archivo (lo que evita que el usuario de la aplicación tenga acceso a cualquier elemento confidencial que pueda estar en /var/log/messages
). ).
Si no tiene ganas de estar sujeto al esquema de permisos tradicional de Usuario/Grupo/Otro, también puede usar las ACL de POSIX (otros procedimientos/información disponible a través de Google, posiblemente mejores) para otorgar al usuario de su aplicación acceso de solo lectura a /var/log/messages
-- esto es un poco más detallado y no corre el riesgo de poner accidentalmente a otra persona en el grupo de la aplicación y darle acceso a cosas que no debería poder ver.
Solución 4:
Sí, he usado setfacl
para hacer esto para dar acceso a la mail.log
archivo para un cliente, no necesitará pegar un comando en el logrotate.conf
archivo para restablecer la ACL después de que se hayan rotado los registros, por ejemplo:
postrotate
/usr/bin/setfacl -m o::r /var/log/mail.log
endscript
Tenga en cuenta que acabo de configurar esto y no lo he probado, pero aunque se publicaría aquí, no puedo ver por qué no funcionaría, que alguien me corrija si me equivoco.