Re: [PATCH] Auditd shutdown credentials
On Wednesday 27 April 2005 17:46, Chris Wright wrote:
> What queue? audit_send_reply does a netlink unicast.
The socket buffer queue. The same one that's causing the problem right
now.
Then we have a bigger problem than this. Look at this code in audit.c:
299 memcpy(data, payload, size);
300 netlink_unicast(audit_sock, skb, pid, MSG_DONTWAIT);
301 return;
We don't check the return code from netlink_unicast or handle it. That needs
to be fixed so that we don't lose it.
> The corresponding user space code reads the netlink socket until
it gets
> the AUDIT_TERM_INFO packet.
So, the real value here is the well-marked packet?
Yes. I can look for well marked packets - its cheap. I cannot parse without
risk of clogging up the backlog and triggering a panic.
In which case, a > sub-type (as you've mentioned a few times
in other
contexts) could be the simplest solution (no requirement for userspace to
ask for kernel to send with anything more than a simple recv()).
I would either need to examine each packet to see if its a TERM_INFO packet
and special handle that, or we'd have a race + compatibility issues. By
asking for the packet, the userspace tools are backwards compatible. You get
a netlink send error and the audit daemon goes ahead and shuts down. By
assuming the kernel will send one, we waiting for something that will never
come.
This reminds me of something I asked for in the past, and that's a
capabilities statement in the get message. It should tell me what features
are compiled in. This will be even more important when we start doing LSPP
since the userspace tools will need to adapt.
-Steve