Quel est le moyen le plus sûr d'autoriser un utilisateur à accéder en lecture à un fichier journal ?

Solution 1 :

Juste pour développer un peu les réponses ci-dessus, voici un cas d'utilisation réel. J'exécute l'application d'analyse de journal d'entreprise Splunk sur une boîte Redhat. Il s'exécute sous l'utilisateur splunk et le groupe splunk. Cela empêche splunk d'accéder aux journaux dans /var/log car ils ne sont accessibles que par root (ou un administrateur sudo)

Afin d'autoriser l'accès en lecture seule pour splunk uniquement, j'ai utilisé certaines ACL et modifié logrotate pour le conserver.

Vous pouvez définir manuellement l'ACL avec

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

Cela ne persistera pas car logrotate ne réappliquera pas le paramètre ACL, donc pour une solution plus permanente, j'ai ajouté une règle à logrotate pour réinitialiser l'ACL. J'ai ajouté le fichier..

/etc/logrotate.d/Splunk_ACLs

avec

{
    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
}

Vérifier l'état ACL d'un fichier avec

$ getfacl /var/log/messages

Pour plus d'informations sur les ACL, voirhttps://help.ubuntu.com/community/FilePermissionsACLshttp://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

Solution 2 :

Pas besoin d'ajouter root au groupe car il aura de toute façon accès via les privilèges de l'utilisateur, donnez simplement la lecture au groupe au groupe que vous décidez. N'oubliez pas d'effectuer également les modifications avec logrotate, sinon les modifications de groupe seront effacées tous les soirs.

Solution 3 :

Votre plan est acceptable et dans le schéma d'autorisations Unix "traditionnel", c'est la meilleure solution.
Une autre option consiste à faire en sorte que syslog détourne les messages d'intérêt vers un autre fichier (ce qui évite de donner à l'utilisateur de l'application l'accès à tout élément sensible pouvant se trouver dans /var/log/messages ).

Si vous n'avez pas envie d'être lié par le schéma d'autorisations traditionnel de l'utilisateur/groupe/autre, vous pouvez également utiliser les ACL POSIX (d'autres guides/informations éventuellement meilleurs disponibles via Google) pour donner à l'utilisateur de votre application un accès en lecture seule à /var/log/messages -- c'est un peu plus précis et ne risque pas de mettre accidentellement quelqu'un d'autre dans le groupe de l'application et de lui donner accès à des choses qu'il ne devrait pas voir.

Solution 4 :

Yip j'ai utilisé setfacl faire cela pour donner accès au mail.log fichier pour un client, non il vous faudra aussi coller une commande dans le logrotate.conf fichier pour réinitialiser l'ACL après la rotation des journaux, par exemple :

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

Notez que je viens juste de configurer cela et que je n'ai pas testé, mais même si cela reviendrait ici, je ne vois pas pourquoi cela ne fonctionnerait pas, quelqu'un me corrige si je me trompe.