Date: Mon, 23 Jul 2001 19:34:44 +0400 From: "Nickolay A.Kritsky" <nkritsky@internethelp.ru> To: "Jeroen Massar" <jeroen@unfix.org> Cc: freebsd-security@FreeBSD.ORG Subject: Re[3]: bin/22595: telnetd tricked into using arbitrary peer ip Message-ID: <47174164064.20010723193444@internethelp.ru> In-Reply-To: <000f01c11379$72391a40$420d640a@HELL> References: <000f01c11379$72391a40$420d640a@HELL>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Jeroen, Monday, July 23, 2001, 5:14:40 PM, you wrote: JM> Matt Dillon <dillon@earth.backplane.com> 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. JM> So... Because they didn't account for this 40 years ago we're stuck with JM> it?? JM> Another proposal, because I know what you mean with the 'old programs' JM> problem which should have been fixed a long time ago with an API :) JM> Quote from my other mail: JM> 8<--- JM> One thing that should be considered to be done if an API is created... : JM> make a backport to previous versions of FreeBSD and actually JM> *BSD/Linux/* :) JM> This also encourages program writers/maintainers to adopt it quicker, as JM> it's less hassle for them and they don't have to make the JM> "pre-FreeBSD-5" case or something... JM> And the best thing of an API (if done right :): seperation of the back JM> and the frontend... which makes changes like this even easier... ---->>8 JM> But now... Make that API log into a different way and place... JM> We will get two wtmp/utmp files then... But then we can let the 'old' JM> 3rd party programs log to the 'old' utmp/wtmp facility. JM> Whenever a 'new' program using the API queries the listing function of JM> the API then the API will simply also check the 'old' facility... Et JM> presto ... We have a solution :) JM> The new solution could log to a database, file whatever you'd do with JM> it.... Just make sure that it fits into an API... :) looks quite reasonable to me - I considered it is the common way of such problems solving. ;------------------------------------------- ; NKritsky ; SysAdmin InternetHelp.Ru ; http://www.internethelp.ru ; mailto:nkritsky@internethelp.ru JM> That's also one of the reasons I am kinda glad that intel simply made JM> IA-64 not IA-32 compliant..... Away with the old stuff and backward JM> compatibility you got emu's (or API's who know the old stuff :) for JM> that... And Windows is going the same way too... NT != DOS ... Luckily JM> :) JM> Greets, JM> Jeroen JM> To Unsubscribe: send mail to majordomo@FreeBSD.org JM> with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47174164064.20010723193444>