From owner-freebsd-security Mon Jul 23 6:19: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by hub.freebsd.org (Postfix) with ESMTP id 45DED37B405; Mon, 23 Jul 2001 06:18:55 -0700 (PDT) (envelope-from jeroen@unfix.org) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id 9D57C319E; Mon, 23 Jul 2001 15:18:44 +0200 (CEST) From: "Jeroen Massar" To: "'Matt Dillon'" Cc: "'Brian Somers'" , "'Hajimu UMEMOTO'" , , , , , Subject: RE: RE: bin/22595: telnetd tricked into using arbitrary peer ip Date: Mon, 23 Jul 2001 15:14:40 +0200 Organization: Unfix Message-ID: <000f01c11379$72391a40$420d640a@HELL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <200107230354.f6N3stj13517@earth.backplane.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Dillon wrote: > All very nice, guys, but not realistic. Only FreeBSD uses an API. > Third party programs access the structure directly for the most > part so adding new fields to the structure will just cause more > garbage to be written to the file (many third party programs > don't bother to bzero the structure before writing it out). We > aren't going to add a separate hostname[] array... we just got > through ripping out the hostname crap, because there was never > enough room in the field to actually store the FQDN, and many > programs don't bother to verify the forward against the > reverse anyway so the data would be suspect. And short > of making a 200+ character array to hold it, which would be masive > bloat, there is no way to fit it in the structure. If > you want to store > host names for posterity you will have to log-process the file and > store the results somewhere else. Every program under > the sun assumes > utmp is a fixed-length structure. > > Pretty much our only option is to extend the size of > existing fields > and take the 'oh hell the structure size changed' hit. So... Because they didn't account for this 40 years ago we're stuck with it?? Another proposal, because I know what you mean with the 'old programs' problem which should have been fixed a long time ago with an API :) Quote from my other mail: 8<--- One thing that should be considered to be done if an API is created... : make a backport to previous versions of FreeBSD and actually *BSD/Linux/* :) This also encourages program writers/maintainers to adopt it quicker, as it's less hassle for them and they don't have to make the "pre-FreeBSD-5" case or something... And the best thing of an API (if done right :): seperation of the back and the frontend... which makes changes like this even easier... ---->8 But now... Make that API log into a different way and place... We will get two wtmp/utmp files then... But then we can let the 'old' 3rd party programs log to the 'old' utmp/wtmp facility. Whenever a 'new' program using the API queries the listing function of the API then the API will simply also check the 'old' facility... Et presto ... We have a solution :) The new solution could log to a database, file whatever you'd do with it.... Just make sure that it fits into an API... :) That's also one of the reasons I am kinda glad that intel simply made IA-64 not IA-32 compliant..... Away with the old stuff and backward compatibility you got emu's (or API's who know the old stuff :) for that... And Windows is going the same way too... NT != DOS ... Luckily :) Greets, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message