bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list
Julian Elischer
julian at elischer.org
Mon Feb 18 10:50:04 PST 2008
The following reply was made to PR bin/120720; it has been noted by GNATS.
From: Julian Elischer <julian at elischer.org>
To: Vadim Goncharov <vadim_nuclight at mail.ru>
Cc: Eugene Grosbein <eugen at kuzbass.ru>, freebsd-ipfw at freebsd.org,
bug-followup at 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 at grosbein.pp.ru>
> References: <200802151642.m1FGgGfQ002038 at grosbein.pp.ru>
>
> Hi Eugene Grosbein!
>
> On Fri, 15 Feb 2008 23:42:16 +0700 (KRAT); Eugene Grosbein
> <eugen at 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.
More information about the freebsd-ipfw
mailing list