From cjc@cc942873-a.ewndsr1.nj.home.com  Tue Jan 18 09:39:02 2000
Return-Path: <cjc@cc942873-a.ewndsr1.nj.home.com>
Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207])
	by hub.freebsd.org (Postfix) with ESMTP id 99EFF14CB7
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 18 Jan 2000 09:39:00 -0800 (PST)
	(envelope-from cjc@cc942873-a.ewndsr1.nj.home.com)
Received: (from cjc@localhost)
	by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id MAA65891;
	Tue, 18 Jan 2000 12:43:43 -0500 (EST)
	(envelope-from cjc)
Message-Id: <200001181743.MAA65891@cc942873-a.ewndsr1.nj.home.com>
Date: Tue, 18 Jan 2000 12:43:43 -0500 (EST)
From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com>
Reply-To: cjc@cc942873-a.ewndsr1.nj.home.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: ipfw(8) poor design of command line parsing
X-Send-Pr-Version: 3.2

>Number:         16179
>Category:       bin
>Synopsis:       ipfw(8) poor design of command line parsing
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 18 09:40:03 PST 2000
>Closed-Date:    Tue Oct 17 06:11:03 PDT 2000
>Last-Modified:  Tue Oct 17 06:12:19 PDT 2000
>Originator:     Crist J. Clark
>Release:        FreeBSD 3.4-STABLE i386
>Organization:
>Environment:

	FreeBSD 3.4-STABLE. It looks like the major problem was
introduced when the option to pre-process IPFW rule files was
added. It exists in 2.2.8-STABLE but occurs under more restricted
conditions.

>Description:

	The design of the ipfw(8) command line parser is poorly
designed. The first check it does is whether the last argument on the
command line is a readable file. If it is, ipfw assumes that it is a
script containing IPFW rules. Therefore, if a user or script ever
executes an ipfw command in which the last argument on the command
line is a readable file, the command will fail if the file is not in
fact a set of IPFW rules.

	I entered this as a 'change request' rather than 'bug,' but it
is a borderline case, IMHO.

>How-To-Repeat:

	The problem was brought to my attention by a user who was
having all commands that ended with the "setup" keyword fail. He had a
file named "setup" in the pwd.

	The code for this in /usr/src/sbin/ipfw.c quite clearly,

        if (ac > 1 && access(av[ac - 1], R_OK) == 0) {

shows this is the intended, coded behavior. The above code is the
first treatment of command line args (ac = argc, av = argv) and if hte
above evaluates true, it is assumed the ipfw command is of the form,

     ipfw [-q] [-p preproc [-D macro[=value]] [-U macro]] file

	Although the occurance of readable files with names of words
that might appear at the end of an ipfw command line is admittedly
low, this problem can be corrected with minor, but non-negligbile,
effort.

>Fix:
	
	To maintain back-compatibility, changing the format for ipfw
command to read IPFW rule files is not a viable solution. The manner
in which command line parsing is done would need
restructuring. One possible method is scanning for keywords at the
begining of a rule (flush, zero, delete, resetlog, list, show, add)
first. If the command  line does not contain one of these, _then_ the
line should be treated as one with a IPFW rule file.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Wed Oct 11 05:17:05 PDT 2000 
State-Changed-Why:  
Fixed in 5.0-CURRENT, ipfw/ipfw.8,v 1.71 and ipfw/ipfw.c,v 1.95. 


Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Wed Oct 11 05:17:05 PDT 2000 
Responsible-Changed-Why:  
Usual MFC reminder. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=16179 
State-Changed-From-To: feedback->closed 
State-Changed-By: ru 
State-Changed-When: Tue Oct 17 06:11:03 PDT 2000 
State-Changed-Why:  
Fixed in RELENG_4 (ipfw/ipfw.c,v 1.80.2.6; ipfw/ipfw.8,v 1.63.2.5). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=16179 
>Unformatted:
