Date: Thu, 7 Mar 2002 21:15:20 -0800 From: Bill Fumerola <billf@mu.org> To: Robert Watson <rwatson@freebsd.org> Cc: Julian Elischer <julian@elischer.org>, Terry Lambert <tlambert2@mindspring.com>, green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308051520.GB803@elvis.mu.org> In-Reply-To: <Pine.NEB.3.96L.1020307225650.32978J-100000@fledge.watson.org> References: <20020308033724.GZ803@elvis.mu.org> <Pine.NEB.3.96L.1020307225650.32978J-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote:
> A couple of comments:
>
> - You can always cache the pcb the first time it's used, and then have it
> available for future use. I agree with your concerns about generating
> it every time -- that would be a disaster for routers where no packets
> are even delivered locally. :-)
you can't cache it and make it available for future use without making
the invasive changes that i mention:
> > first, having a uid or gid rule in your ipfw ruleset (or even running
> > ipfw) certainly isn't the common case. we're now going to bloat the
> > ip_fw_chk() calls protocol handler calls to add an arguement that 99%
^-- "and"
> > of time is going to be NULL. then you have to bloat the protocol handlers
> > to check if that pointer, that is NULL 99% of the time, isn't NULL.
i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene.
adding another one to the protocol handlers doesn't seem like a great
idea either.
we're talking about an optimization that less then .1% of our userbase
will ever take advantage of v. a pessimization (additional argument in
the protocol handler + check of that arguement in the handler) in the
critical path of packet delivery in ALL cases (even kernels w/o ipfw).
it's just not worth it.
with ipfw cacheing the pcb lookup + credential check and w/o terry's
patch, the worst case would be a ruleset with any uid/gid rules: a pcb
lookup being done twice (once ever in ipfw, once in the protocol handler).
that's really not so bad compared with the current behavior with uid/gid
rules where the lookup is done of a lot of times (as many uid/gid rules
you walk through before you match) in ipfw and once in the protocol
handler.
> - The uid/gid code is broken for a number of important applications,
> including SSH forwarding, because SSHd binds the socket using a root
> credential rather than the user credential. Arguably, this is a bug
> with SSHd, and it also breaks a number of other things including the MAC
> support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs
> involving NFS that I recently fixed in 5.0-CURRENT, where sockets were
> rebound using the credential of the user making the VFS operation,
> resulting in ipfw uid/gid rules dropping/rate-limiting file system
> requests for all users. For those running into the whole sshd tunnel
> and ident problem, it's the same cause.
i would like to make my cache have the proper credential(s) rather then
just cache the current socket credentials cr_uid, if that's wrong.
please let me know privately just what exactly i should be comparing
against (or functions i should be using, if an API exists now) in -current
with the changes to credentials.
when i mfc the cache, i'll just keep the current uid comparing behavior.
--
- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org
- my anger management counselor can beat up your self-affirmation therapist
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020308051520.GB803>