[PATCH] Auditd shutdown credentials

[Steve Grubb]

On Thursday 28 April 2005 16:57, Chris Wright wrote:
> > 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.

Yes we are draining trying to find the packet. Just queuing it in the head of 
the list would be sufficient. Which brings up the point that this packet has 
priority over anything else in the queue if its also full. We can dump the 
whole queue to /dev/null or syslog to make room.

Let me throw something out...it came up in some discussions over the SE Linux 
policy that were implementing that maybe the best solution is to have 2 
netlink socket types. One for command and control and one for spewing events. 
This way the command and control channel is always empty. Personally, I think 
its too late for this idea.

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

I like the TERMINFO situation better. I think you saw the reasons farther down 
the list. But...

I got to thinking about something this afternoon. If we support SIGHUP to 
reload the audit daemon, we have the same issue...who issued the reload 
command? We will need to hook SIGHUP as well in that case...and then the name 
TERMINFO doesn't seem right anymore. :\

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

We should start a new thread for this.

-Steve