[PATCH] Auditd shutdown credentials

[Chris Wright]

* Steve Grubb (sgrubb at redhat.com) wrote:
> 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.

That's exactly what I was trying to get at.  Choices are...it's dropped
(silently), or it's in the queue, at which point you're draining in hopes
of finding it.  Which leaves me wondering if the signal hook just does
a simple audit_log_type(TERMINFO, "blah") would be good?  This will hook
into the retry logic at least.

> > > 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.

I see you point better now.  You should never get the TERM_INFO payload
before the signal handler runs.  But that doesn't handle backwards
compatibility.  I hadn't even considered that was an issue here.

> 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.

Seems very reasonable.  What was the list of features you thought were
useful?

thanks,
-chris