Date: Thu, 7 Mar 2002 23:03:19 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Bill Fumerola <billf@mu.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: <Pine.NEB.3.96L.1020307225650.32978J-100000@fledge.watson.org> In-Reply-To: <20020308033724.GZ803@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :-) - 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. Now we have a combined pcred/ucred in ucred, in theory the rules could also act on effective/real/saved credentials, although that might not be useful. Actually, it arguably might be for setuid network tools. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > > what would be even nicer is if ipfw found the cached entry and passed it > > back to ip_input so it didn't need to :-) > > i think this entire idea of cacheing it in ip_input() is a bad idea, no > offense terry. > > 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% > 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 just don't think that the gain in the edge case justifies the slowdown > in the common case. the first person to say 'sysctl' or '#ifdef' gets > to drink from the fire hose. > > second, the real travesty is that if you have N rules in ipfw that > reference a uid or gid, you will do a pcb lookup on the same packet for > each of those N rules until you match. the worst case scenario of having > to do a lookup for each uid rule is what the charts in my previous post > measure. > > terry asked in his post: "NB: Is there a particular reason Bill's changes > haven't simply been committed?", the reason is that my cache of the pcb > and uid was done in my compiledipfw code, not the mainline ipfw. its > really not a straight port because of somethings that compiledipfw keeps > state on before generating code (skiptos, mostly); ipfw would have to > be more careful then the generated code needs to be. > > if brian feldman (the author of the ipfw uid/gid code) doesn't fix this > out of embarassment first, i'll backport my cache into the main ipfw > code. > > -- > - 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-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020307225650.32978J-100000>