From owner-freebsd-hackers Sun Apr 4 23:37:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5381514FAD for ; Sun, 4 Apr 1999 23:37:11 -0700 (PDT) (envelope-from julian@whistle.com) Received: from s204m82.isp.whistle.com (s204m82.isp.whistle.com [207.76.204.82] (may be forged)) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA53777; Sun, 4 Apr 1999 23:32:41 -0700 (PDT) Date: Sun, 4 Apr 1999 23:32:22 -0700 (PDT) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Peter Wemm Cc: "Matthew N. Dodd" , Brian Feldman , hackers@FreeBSD.ORG Subject: Re: ipfw uid In-Reply-To: <199904050554.NAA06717@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Apr 1999, Peter Wemm wrote: > At one point I was toying with the idea of trying to do something like this > kind of counting at the socket level, rather than at the packet stream > level. Sure, it would have lost the packet overheads, but it should be > easier.. > > Cheers, > -Peter One reason to do it at the socket level is that UID accounting can only work on the local level anyway. Doing it at the lower levels uses resources for all traffic local or not.. You also get charged for all retries etc which may, or may not, be fair depending on your point of view. Also doing it at socket layer allows you to not incur any work in the case of excempt processes. Whether a process should or should not be charged can be cached in the socket structure rather than being worked out on the fly each time. I don't think the ipfw interface is the right place for this. ipfw is acting as a cancerous growth. Speaking as one of the culprits, I think it's possibly time to think about the careful cleaning of hte FreeBSD stacks. Garret has som good work in the wings re: the tcp timers, but there are a number of really messy parts. e.g. rtentries refer directly to interfaces in a number of places where they should refer to the ifaddrs. reference counting between ifaddrs and ifnets and rtentries is pretty much broken, and only works by 'good will'. The ability to invalidate addresses and interfaces is held together by chewing gum. Recovery of old rtentries is in great need of cleaning up. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message