From: Steve Grubb <sgrubb@redhat.com>
To: LC Bruzenak <lenny@magitekltd.com>
Cc: linux-audit@redhat.com
Subject: Re: user message limits
Date: Wed, 28 Jan 2009 15:14:04 -0500 [thread overview]
Message-ID: <200901281514.05301.sgrubb@redhat.com> (raw)
In-Reply-To: <1233164667.30154.142.camel@homeserver>
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
next prev parent reply other threads:[~2009-01-28 20:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 0:01 user message limits LC Bruzenak
2009-01-28 15:30 ` LC Bruzenak
2009-01-28 17:15 ` Steve Grubb
2009-01-28 17:44 ` LC Bruzenak
2009-01-28 20:14 ` Steve Grubb [this message]
2009-01-28 20:30 ` LC Bruzenak
2009-01-28 21:04 ` LC Bruzenak
2009-01-28 23:37 ` Casey Schaufler
2009-01-28 23:52 ` LC Bruzenak
2009-01-29 0:36 ` Casey Schaufler
2009-01-29 6:57 ` James W. Hoeft
2009-01-30 4:49 ` Casey Schaufler
2013-09-17 14:48 ` Richard Guy Briggs
2013-09-17 18:10 ` Steve Grubb
2013-09-18 2:25 ` Richard Guy Briggs
2013-09-18 14:25 ` Steve Grubb
2013-09-18 15:10 ` spurious \n in session id helper [was: Re: user message limits] Richard Guy Briggs
2009-06-08 22:08 ` user message limits LC Bruzenak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200901281514.05301.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=lenny@magitekltd.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox