Re: tcpd remarks warning

[pmarc () cmg fcnbd com (Paul M. Cardon)]

"Stefano Torricella <thor () IRCITY ORG>" thus spake unto me:
: the bash or the bourne shell ignore \ on the comment line !
: Thinking that this is a general behavior for all the unix program i've
: contacted the author and manteiner of tcpd but for him this is correct.
: In all the case this may be dangerous so other sysadm may be interested on
: this behaviour

Here is the relevant portion of the hosts_access(5) man page for
tcp_wrappers version 7.6:

ACCESS CONTROL RULES
     Each access control file consists of zero or more lines of
     text.  These lines are processed in order of appearance. The
     search terminates when a match is found.

     +    A newline character is ignored when it is preceded by a
          backslash character. This permits you to break up long
          lines so that they are easier to edit.

     +    Blank lines or lines that begin with a `#' character
          are ignored.  This permits you to insert comments and
          whitespace so that the tables are easier to read.


If you make the assumption that the rules are applied as listed in the man
page then the observed behavior of line continuation processing occuring
prior to comment stripping matches the documentation.  However, it should be
stated explicitly in the documentation because of the potential unexpected
behavior noted by Stefano.

When config files are read, the function xgets() /* fgets() with
backslash-newline stripping */ in misc.c is called.  The calling functions
_then_ check for comment lines and skip them (see hosts_access.c, inetcf.c,
and tcpdchk.c).  It's easy enough to change this behavior in xgets by
replacing:

        if (got >= 2 && ptr[got - 2] == '\\') {

with:

        if (ptr[0] == '#') {
            return (start);
        } else if (got >= 2 && ptr[got - 2] == '\\') {

I see nothing wrong with a program parsing its own config files the way it
wants as long as the behavior is clearly documented.  However, code in
inetcf.c parses inetd.conf with line continuation, something that inetd does
not do in any implementation I have seen.  Fortunately, this does not affect
the functionality of tcpd itself since it doesn't use the code in inetcf.c.
While I believe it is unlikely that a backslash would be placed at the end of
a comment line in inetd.conf, tcpdmatch and tcpdcheck could miss problems in
inetd.conf that the user would expect to see reported.  That's a bug.

-paul