Re: user message limits
On Tuesday, September 17, 2013 10:25:23 PM Richard Guy Briggs wrote:
On Tue, Sep 17, 2013 at 02:10:19PM -0400, Steve Grubb wrote:
> This is defined in the ABI:
>
> #define MAX_AUDIT_MESSAGE_LENGTH 8970 //
> PATH_MAX*2+CONTEXT_SIZE*2+11+256+1
So, 4096*2 + ?*2 + 11 + 256 + 1 means CONTEXT_SIZE is 255? Is this
better documented somewhere?
I believe this was based on
#define INITCONTEXTLEN 255
> It cannot change without recompiling all of user space.
Of course. I'm curious how it is used.
Setting buffers on the stack. Immediately below that define is:
struct audit_message {
struct nlmsghdr nlh;
char data[MAX_AUDIT_MESSAGE_LENGTH];
};
and that gets used by user space in various programs. I think we've run into
problems with pam in the past if the constant ever changes. The constant was
designed at the time to handle the largest record known, AUDIT_PATH. It might
need adjusting upward as I think a couple things have been added over the
years.
If userspace can't actually make use of that, then it should be
changed, or
the other limitations fixed. I suspect a kernel limitation, but would need
to investigate more.
User space needs an idea of the largest possible event its expected to handle.
Some apps have to be very reliable in terms of auditing and they make use of
the stack so there is no chance of leaks or memory fragmentation.
> But the kernel always
>
> includes this in any event:
> audit_log_format(ab, "audit(%lu.%03lu:%u): ",
>
> t.tv_sec, t.tv_nsec/1000000, serial);
>
> an unsigned is 4 bytes and long unsigned is 8 bytes. Translated to decimal
>
> 4026531839
> 18446744073709551615
>
> So, I'd say the header can occupy 43 bytes max.
I'm not sure where you got that 4-byte max decimal, but it has the right
number of digits... ;-) I get 11 chars for formatting, 20 for the
first number, 3 for the second and 10 for the last, giving 44.
> (All the following numbers
> assume maximum size.) Then if you look at the message body, it starts by
> logging an identifier "user ", which is 5 bytes. Then:
Where is this? I don't see it.
Looks like it has been dropped some time recently. But its in old kernels such
as 2.6.32.
> audit_log_format(*ab, "pid=%d uid=%u",
task_tgid_vnr(current), uid);
> which my count is 29 bytes maximum.
Yup.
> and then session information:
> audit_log_format(ab, " auid=%u ses=%u\n", auid, sessionid);
> which is 32 characters...but I don't know why the \n is in there. That
> should probably be deleted!!
That is unexpected... added in 4d3fb709 when the session id was
refactored (by eparis(a)localhost.localdomain nonetheless!). auditd seems
to be doing the right thing when writing out /var/log/audit/audit.log
though.
Please drop the '\n' as I mentioned above. It doesn't belong there and wastes
room in the audit trail. Auditd strips all '\n' and it would run faster if it
didn't have to strip it out.
-Steve