Hello Lubomir,
Thanks for the patch...but I think that why this is not currently addressed in
the code is something like this. Let's assume the system has 5 audit logs with
600 root.
If an admin decides to allow a group to read the audit logs, they will have
to:
1) create the group
2) add users to the group
3) change the auditd.conf file
4) chgrp -R group /var/log/audit
5) chmod 0750 /var/log/audit
6) chmod 0640 /var/log/audit/*
7) restart the audit daemon
What this patch does is part of step 4 and 6. It would change audit.log to be
readable, but would leave audit.log.1 -> audit.log.4 untouched. Because
allowing a group requires so many steps, it's always been left as an admin
exercise...just like revoking group access would.
-Steve
On Friday, July 25, 2014 01:59:04 PM Lubomir Rintel wrote:
Link:
https://bugzilla.redhat.com/show_bug.cgi?id=1118313
Link:
https://bugzilla.redhat.com/show_bug.cgi?id=1118262
---
src/auditd-event.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/auditd-event.c b/src/auditd-event.c
index 4fa266e..66dff34 100644
--- a/src/auditd-event.c
+++ b/src/auditd-event.c
@@ -1130,6 +1130,12 @@ static void reconfigure(struct auditd_consumer_data
*data) // log format
oconf->log_format = nconf->log_format;
+ // log group
+ if (oconf->log_group != nconf->log_group) {
+ oconf->log_group = nconf->log_group;
+ need_reopen = 1;
+ }
+
// action_mail_acct
if (strcmp(oconf->action_mail_acct, nconf->action_mail_acct)) {
free((void *)oconf->action_mail_acct);