[PATCH] Auditd shutdown credentials

Steve Grubb sgrubb at redhat.com
Wed Apr 27 22:22:47 UTC 2005


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




More information about the Linux-audit mailing list