Lösung 1:
Um die obigen Antworten ein wenig zu erweitern, hier ein realer Anwendungsfall. Ich führe die Anwendung Splunk zur Analyse von Unternehmensprotokollen auf einer Redhat-Box aus. Es wird unter dem Splunk-Benutzer und der Splunk-Gruppe ausgeführt. Dies verhindert, dass Splunk auf die Protokolle in /var/log zugreift, da sie nur für Root (oder einen Sudo-Administrator) zugänglich sind
Um schreibgeschützten Zugriff nur für Splunk zu ermöglichen, habe ich einige ACLs verwendet und logrotate modifiziert, um es zu behalten.
Sie können die ACL manuell mit
festlegensudo setfacl -m g:splunk:rx /var/log/messages
Dies wird nicht bestehen bleiben, da logrotate die ACL-Einstellung nicht erneut anwendet, also habe ich für eine dauerhaftere Lösung eine Regel zu logrotate hinzugefügt, um die ACL zurückzusetzen. Ich habe die Datei hinzugefügt..
/etc/logrotate.d/Splunk_ACLs
mit
{
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
}
Überprüfen Sie den ACL-Status einer Datei mit
$ getfacl /var/log/messages
Weitere Informationen zu ACLs finden Sie unter https://help.ubuntu.com/community/FilePermissionsACLshttp://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/
Lösung 2:
Es ist nicht erforderlich, root zur Gruppe hinzuzufügen, da sie sowieso Zugriff über die Benutzerprivilegien hat. Geben Sie der Gruppe einfach Lesezugriff für die Gruppe, für die Sie sich entscheiden. Denken Sie daran, die Änderungen auch mit logrotate vorzunehmen, sonst werden die Gruppenänderungen jede Nacht gelöscht.
Lösung 3:
Ihr Plan ist akzeptabel und im "traditionellen" Unix-Berechtigungsschema der beste Weg.
Eine weitere Option besteht darin, dass Syslog die interessierenden Nachrichten in eine andere Datei umleitet (wodurch vermieden wird, dass der App-Benutzer Zugriff auf sensible Daten erhält, die sich möglicherweise in /var/log/messages
befinden ).
Wenn Sie nicht an das traditionelle Berechtigungsschema von Benutzer/Gruppe/Andere gebunden sein möchten, können Sie auch POSIX-ACLs (andere, möglicherweise bessere Anleitungen/Informationen, die über Google verfügbar sind) verwenden, um Ihrem App-Benutzer schreibgeschützten Zugriff auf /var/log/messages
-- dies ist etwas detaillierter und riskiert nicht, versehentlich jemand anderen in die Gruppe der Anwendung aufzunehmen und ihm Zugriff auf Dinge zu gewähren, die er nicht sehen sollte.
Lösung 4:
Ja, ich habe setfacl
verwendet um dies zu tun, um Zugriff auf mail.log
zu gewähren Datei für einen Kunden, nicht Sie müssen auch einen Befehl in die logrotate.conf
einfügen Datei, um die ACL zurückzusetzen, nachdem die Protokolle rotiert wurden, z. B.:
postrotate
/usr/bin/setfacl -m o::r /var/log/mail.log
endscript
Hinweis:Ich habe dies gerade erst eingerichtet und noch nicht getestet, aber obwohl es hier zurück gepostet würde, kann ich nicht sehen, warum es nicht funktionieren würde, jemand korrigiert mich, wenn ich falsch liege.