From owner-freebsd-hackers Thu Mar 7 20: 3:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C731A37B405; Thu, 7 Mar 2002 20:03:31 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g2843JD42713; Thu, 7 Mar 2002 23:03:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 7 Mar 2002 23:03:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bill Fumerola Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308033724.GZ803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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-hackers" in the body of the message