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
Respuestas:
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/
/etc/logrotate.d/Splunk_ACLsque has publicado allí? ¿Realmente no necesita especificar ninguna ruta para que logrotate procese el bit de postrotación?
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.