Re: audit_pid with multiple userspace auditd processes

On Wednesday 07 January 2009 04:36:39 pm Eric Paris wrote: > lets say userspace starts 2 copies of auditd. # auditctl -s AUDIT_STATUS: enabled=1 flag=1 pid=4488 rate_limit=0 backlog_limit=512 lost=1 backlog=0 # /sbin/auditd # auditctl -s AUDIT_STATUS: enabled=1 flag=1 pid=0 rate_limit=0 backlog_limit=512 lost=1 backlog=0 # ps -ef | grep auditd root 580 2 0 08:19 ? 00:00:00 [kauditd] root 4488 1 0 16:35 ? 00:00:00 auditd root 5128 3654 0 17:33 pts/1 00:00:00 grep auditd > Then they kill the first copy. The kernel at that point thinks there is no > userspace auditd running and will instead send things to dmesg Looks to me like the kernel is setting auditd_pid to 0 and the second auditd does not start - at least with my current setup. For some other setups, it probably overwrites the pid with the new one and keeps going. > We could fix it by changing the handling in audit_receive_msg to reject > setting the audit_pid to 0 if the current audit_nlk_pid != > NETLINK_CB(skb).pid. Well, what if the first crashed and the kernel didn't know it yet? It might be better to forcibly break the connection to the original auditd.

> It's not a big deal, maybe we just call results of audit with multiple > userspace auditd's running at the same time a undefined and not care. What do you get for auditctl -s before and after starting your second auditd?