From owner-freebsd-net Thu Mar 7 21:15:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5B99C37B405; Thu, 7 Mar 2002 21:15:20 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 245A4AE211; Thu, 7 Mar 2002 21:15:20 -0800 (PST) Date: Thu, 7 Mar 2002 21:15:20 -0800 From: Bill Fumerola To: Robert Watson Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308051520.GB803@elvis.mu.org> Reply-To: Bill Fumerola References: <20020308033724.GZ803@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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-net" in the body of the message