From cjc@cc942873-a.ewndsr1.nj.home.com  Mon Feb 21 20:22:29 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 7024F37B67F
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 21 Feb 2000 20:22:26 -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 XAA04355;
	Mon, 21 Feb 2000 23:27:38 -0500 (EST)
	(envelope-from cjc)
Message-Id: <200002220427.XAA04355@cc942873-a.ewndsr1.nj.home.com>
Date: Mon, 21 Feb 2000 23:27:38 -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: Bad error flagging in natd(8) config file read
X-Send-Pr-Version: 3.2

>Number:         16900
>Category:       bin
>Synopsis:       Bad error flagging in natd(8) config file read
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 21 20:30:00 PST 2000
>Closed-Date:    Fri Feb 25 03:42:58 PST 2000
>Last-Modified:  Fri Feb 25 03:44:10 PST 2000
>Originator:     Crist J. Clark
>Release:        FreeBSD 3.4-STABLE i386
>Organization:
>Environment:

	Present in all versions of FreeBSD checked up to 3.4-STABLE.

>Description:

	natd(8) will choke and die on a configuration file if the last
line of the file does not end in a newline. It does not matter whether
the line is even a natd option. natd will bail if the last line is a
comment and does not end in a newline (which is how I found this).

	That in itself is not necessarily a bug. What is a bug is that
natd improperly flags the error as,

             natd: config line too long: <last line>

>How-To-Repeat:

	This will occur anytime a natd configuration file is valid
until the last line without a newline.

>Fix:
	
	The workaround is to realize natd is misinterpretting the
situation and put a newline in your config file.

	There are two ways to have natd properly handle this. (1)
Flag a file with no newline on the last line, or (2) accept a file
with no newline on the last line.

	Here is the patch for (1),

--- /usr/src/sbin/natd/natd.c   Fri Jan 28 04:02:05 2000
+++ natd.c      Mon Feb 21 23:03:36 2000
@@ -1263,7 +1263,10 @@
 
                ptr = strchr (buf, '\n');
-               if (!ptr)
-                       errx (1, "config line too long: %s", buf);
+               if (!ptr) {
+                       ptr = strchr (buf, '\0');
+                       if ( ptr && ( ( ptr - buf + 1 ) < sizeof (buf) ) )
+                              errx (1, "no newline at end of config file: %s", buf);
+                       else
+                              errx (1, "config line too long: %s", buf);
+               }
  
                *ptr = '\0';


	However, here is the patch for my preference, (2),

--- /usr/src/sbin/natd/natd.c   Fri Jan 28 04:02:05 2000
+++ natd.c      Mon Feb 21 23:12:32 2000
@@ -1262,8 +1262,11 @@
        while (fgets (buf, sizeof (buf), file)) {
 
                ptr = strchr (buf, '\n');
-               if (!ptr)
-                       errx (1, "config line too long: %s", buf);
+               if (!ptr) {
+                       ptr = strchr (buf, '\0');
+                       if ( ptr && ( ( ptr - buf + 1 ) == sizeof (buf) ) )
+                               errx (1, "config line too long: %s", buf);
+               }
 
                *ptr = '\0';


I tested a little, but they are quick fixes. I may have overlooked
something.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Tue Feb 22 06:55:38 PST 2000 
Responsible-Changed-Why:  
Will fix it tomorrow. 
State-Changed-From-To: open->closed 
State-Changed-By: ru 
State-Changed-When: Fri Feb 25 03:42:58 PST 2000 
State-Changed-Why:  
Fixed in 4.0-current and 3.4-stable. 
>Unformatted:
