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. Fix: The following patch does three things: 1) revert default behavour to match 6.2-RELEASE and earlier; 2) offer new way to format value as IP with new switch "ipfw -i": ipfw -i table 1 list 3) document both variants in the ipfw(8) manual page. The patch applies to both of RELENG_6 and RELENG_7. Eugene Grosbein--zjxnaHdQEbbyeH1lnt7yk6UNjgBzBWHAvraXEwgMZaSMTdqd Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- sbin/ipfw/ipfw.8.orig 2008-02-15 23:18:10.000000000 +0700 +++ sbin/ipfw/ipfw.8 2008-02-15 23:18:04.000000000 +0700 @@ -210,6 +210,12 @@ if misused, .No i.e. Cm flush . If there is no tty associated with the process, this is implied. +.It Fl i +While +.Cm list Ns ing table (see the +.Sx LOOKUP TABLES +section below for more information on lookup tables), format values +as IP addresses. By default, values are shown as integers. .It Fl n Only check syntax of the command strings, without actually passing them to the kernel. --- sbin/ipfw/ipfw2.c.orig 2008-02-15 17:26:53.000000000 +0700 +++ sbin/ipfw/ipfw2.c 2008-02-15 23:24:30.000000000 +0700 @@ -62,6 +62,7 @@ #include <arpa/inet.h> int + do_value_as_ip, /* show table value as IP */ do_resolv, /* Would try to resolve all */ do_time, /* Show time stamps */ do_quiet, /* Be quiet in add and flush */ @@ -5028,7 +5029,7 @@ /* values < 64k are printed as numbers */ unsigned int tval; tval = tbl->ent[a].value; - if (tval > 0xffff) { + if (do_value_as_ip) { char tbuf[128]; strncpy(tbuf, inet_ntoa(*(struct in_addr *) &tbl->ent[a].addr), 127); @@ -5039,7 +5040,7 @@ } else { printf("%s/%u %u\n", inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), - tbl->ent[a].masklen, tbl->ent[a].value); + tbl->ent[a].masklen, tval); } } } else @@ -5148,7 +5149,7 @@ save_av = av; optind = optreset = 0; - while ((ch = getopt(ac, av, "abcdefhnNqs:STtv")) != -1) + while ((ch = getopt(ac, av, "abcdefhinNqs:STtv")) != -1) switch (ch) { case 'a': do_acct = 1; @@ -5180,6 +5181,10 @@ help(); break; /* NOTREACHED */ + case 'i': + do_value_as_ip = 1; + break; + case 'n': test_only = 1; break; 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.
Responsible Changed From-To: freebsd-bugs->freebsd-ipfw Over to maintainer(s).
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. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
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.
State Changed From-To: open->closed Patch committed to -current and scheduled for MFC.
julian 2008-02-18 19:56:10 UTC FreeBSD src repository Modified files: sbin/ipfw ipfw.8 ipfw2.c Log: Instead of using a heuristic to decide whether to display table 'values' as IP addresses, use an explicit argument (-i). This is a 'POLA' issue. This is a low risk change and should be MFC'd to RELENG_6 and RELENG 7. it might be put as an errata item for 6.3. (not sure about 6.2). Fix suggested by: Eugene Grosbein PR: 120720 MFC After: 3 days Revision Changes Path 1.209 +5 -0 src/sbin/ipfw/ipfw.8 1.114 +9 -6 src/sbin/ipfw/ipfw2.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
On Mon, Feb 18, 2008 at 10:32:32AM -0800, Julian Elischer wrote: > 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. In RELENG_4, they are 32bit. > 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's very suitable for automatic time-bounded blocking. A trigger adds IP being blocked to ipfw table with 32-bit value that is "time-to-live" value for this table entry, and there is a rule like this: ipfw add 1000 deny ip from 'table(1)' to any Cron periodically runs another script that lists the table and removes entries with time in the past. Thank you for fixing that! Eugene Grosbein
Hi! This PR was closed 6 weeks ago and had a record "MFC After: 3 days". http://www.freebsd.org/cgi/query-pr.cgi?pr=120720 There is still no MFC to RELENG_7 nor to RELENG_6 where POLA was broken. Please do it. Eugene Grosbein
The change has been MFC'd to RELENG_6 and RELENG_7
On Fri, Apr 04, 2008 at 11:12:39AM -0700, Julian Elischer wrote: > The change has been MFC'd to RELENG_6 and RELENG_7 Thank you!