user message limits

[Steve Grubb]

On Wednesday 28 January 2009 12:44:27 pm LC Bruzenak wrote:
> On Wed, 2009-01-28 at 12:15 -0500, Steve Grubb wrote:
> > Offhand, I don't remember why the kernel sets the limit so low. It could
> > be bumped some. How much, I don't know. 4K or 8K would seem fine.
>
> To me the primary thing is consistency with the input text size.
> Seems strange to successfully send in some data and be unable to
> retrieve it.

Sure, but netlink is asynchronous. There is no way to tell user space that the 
payload sent was too big unless you hit a netlink internal limit.


> A secondary concern is - what is the input limit?

The code says it will print up to 1024 chars, some of which comes from 
libaudit.


> If the total input buffer size is 8K and some of that needs to be used
> internally (by audit lib), maybe it should be clamped at 7K?

Well, here is a problem. All current kernels only allow 1024. If we make that 
bigger, then the only thing I can do to reliably determine this is to check 
at runtime what the kernel version is. uname() is an ugly way to do this when 
you consider that a kernel could be patched to increase the limit.


> I'm trying to avoid a lot of retry logic on the sending side, where if a
> failure occurs, we would truncate and resend until it passes. I guess if
> I were certain that 7K is always going to fit I could artificially clamp
> my own input there, but it seems better if it were universally constant.

For the time being, you'll need to clamp your input to maybe about 950 chars. 
In all the work I've done patching everything, I've never needed to send more 
than 200 bytes or so. 

-Steve