¿Cuál es la forma más segura de permitir que un usuario lea el acceso a un archivo de registro?

Mi aplicación requiere acceso de lectura /var/log/messages, que pertenece al usuario y al grupo root. ¿Cuál es el nivel mínimo de exposición requerido /var/log/messagespara que mi aplicación pueda leerlo?

Actualmente, mi plan es cambiar la propiedad del grupo /var/log/messagesa un nuevo grupo y agregarle la raíz y el usuario de mi aplicación, pero esto también le daría privilegios de escritura a la aplicación /var/log/messages.

OS: Centos 5.5

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 hacer los cambios con logrotate también o los cambios del grupo se borrarán todas las noches.

Solo para expandir un poco las respuestas anteriores aquí hay un caso de uso del mundo real. Ejecuto la aplicación de análisis de registro empresarial Splunk en un cuadro de 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 por root (o un administrador de sudo)

Para permitir el acceso de solo lectura solo para splunk, he usado algunas ACL y modifiqué el logrotate para mantenerlo.

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 para 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 las ACL, consulte https://help.ubuntu.com/community/FilePermissionsACL http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

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 acceda a cualquier cosa sensible que pueda estar /var/log/messages)

Si no tiene ganas de estar obligado por el esquema de permisos tradicional de Usuario / Grupo / Otro, también puede usar las ACL POSIX (otros, posiblemente mejores instrucciones / información disponibles a través de Google) para dar a su usuario de la aplicación acceso de solo lectura a /var/log/messages- esto es un poco más detallado y no se arriesga a poner accidentalmente a otra persona en el grupo de la aplicación y les da acceso a cosas que no deberían poder ver.

Sí, solía setfaclhacer esto para dar acceso al mail.logarchivo a un cliente, no es necesario que también pegue un comando en el logrotate.confarchivo para restablecer la ACL después de que se hayan girado 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 volvería a publicarse aquí, no puedo ver por qué no funcionaría, alguien me corrige si me equivoco.

Puede usar ACL para esto. Le permite establecer reglas de acceso adicionales específicas para usuarios y archivos específicos.

una vez que configuró su ACL como dijeron otras personas, en lugar de poner todas sus reglas de acl en la configuración postrotate, puede usar logrotate para usar copytruncate en lugar de crear un nuevo archivo de registro cada vez