Re: user message limits
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