audit_pid with multiple userspace auditd processes

[Steve Grubb]

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?

-Steve