Re: [PATCH] Auditd shutdown credentials
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