回答:
とにかくユーザーprivsを介してアクセスできるため、グループにルートを追加する必要はありません。グループに、あなたが決めたグループの読み取りを許可するだけです。logrotateを使用して変更を加えることも忘れないでください。そうしないと、グループの変更が毎晩消去されます。
上記の回答を少し拡大するだけで、実際の使用例になります。Redhatボックスでエンタープライズログ分析アプリケーションSplunkを実行します。splunkユーザーとsplunkグループの下で実行されます。/ var / logのログにアクセスできるのは、root(またはsudo管理者)のみであるため、これによりsplunkがアクセスできなくなります。
splunkのみに読み取り専用アクセスを許可するために、いくつかのACLを使用し、logrotateを変更して永続化しました。
手動でACLを設定できます
sudo setfacl -m g:splunk:rx /var/log/messages
logrotateはACL設定を再適用しないため、これは持続しません。そのため、より永続的な解決策として、ACLをリセットするためにlogrotateのルールを追加しました。ファイルを追加しました。
/etc/logrotate.d/Splunk_ACLs
と
{
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
}
ファイルのACLステータスを確認します
$ getfacl /var/log/messages
ACLの詳細については、https ://help.ubuntu.com/community/FilePermissionsACLs http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/を参照して ください。
/etc/logrotate.d/Splunk_ACLs
あなたがそこに投稿した内容全体ですか?実際に、後回転ビットを処理するためにlogrotateのパスを指定する必要はありませんか?
あなたの計画は受け入れられており、「伝統的な」Unixパーミッションスキームが最善の方法です。
別のオプションは、syslogに関心のあるメッセージを別のファイルに転送させることです(これにより、アプリのユーザーがにある可能性のある機密情報にアクセスすることを回避できます/var/log/messages
)。
User / Group / Otherの従来のアクセス許可スキームに縛られたくない場合は、POSIX ACL(その他、Googleで利用可能なより良いhowtos / info)を使用して、アプリユーザーに読み取り専用アクセスを許可することもできます/var/log/messages
-これはもう少しきめ細かく、誤って他の誰かをアプリケーションのグループに入れて、見るべきではないものにアクセスできるようにするリスクはありません。