Date: Mon, 18 Feb 2008 18:50:03 GMT From: Julian Elischer <julian@elischer.org> To: freebsd-ipfw@FreeBSD.org Subject: Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list Message-ID: <200802181850.m1IIo3uX090403@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/120720; it has been noted by GNATS. From: Julian Elischer <julian@elischer.org> To: Vadim Goncharov <vadim_nuclight@mail.ru> Cc: Eugene Grosbein <eugen@kuzbass.ru>, freebsd-ipfw@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list Date: Mon, 18 Feb 2008 10:32:32 -0800 Vadim Goncharov wrote: > In-Reply-To: <200802151642.m1FGgGfQ002038@grosbein.pp.ru> > References: <200802151642.m1FGgGfQ002038@grosbein.pp.ru> > > Hi Eugene Grosbein! > > On Fri, 15 Feb 2008 23:42:16 +0700 (KRAT); Eugene Grosbein > <eugen@kuzbass.ru> wrote: > >> The command "ipfw table 1 list" used to format table values >> associated with network addresses as 32-bit unsigned integers >> until 6.3-RELEASE. Since 6.3-RELEASE, it interprets values >> that are greater than 65535 as IP-addresses. > >> This change breaks many existing applications that expect the format >> to be an integer, as it used to be since RELENG_4. >> This change is not even documented. So, it breaks POLA and should be >> corrected. > >>> How-To-Repeat: > >> ipfw table 1 add 1.1.1.1 $(date +%s) >> ipfw table 1 list > >> This used to show something like "1.1.1.1/32 1203093427" before change >> but now it shows something like "1.1.1.1/32 71.181.191.179" instead. > > Confirming. This breaks UNIX-time using scripts for many systems and was > introduced by ``ipfw fwd tablearg'' handling commit to 6.2-STABLE in May > 2007. > > POLA should be unbroken as far as possible. that was me.. It is my memory that before that time tableargs were only used in 16 bit form. there were no users in ipfw of the full 32 bit field. I did not consider that someone would put a 32 bit number in there just to print it out again. (what would you do that for?) It shows that even if you were involved in writing code you can never predict what your users will do with it. I'll add an argument to force the interpretation.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802181850.m1IIo3uX090403>