[ On Friday, April 2, 1999 at 09:32:59 (+0200), Stefano Torricella wrote: ]
> Subject: tcpd remarks warning
>
> i think that when a remark line is found, the parser must go to the
> next line without checking what is in the comment line.
>
> if you write a simple shell program :
> #!/bin/sh
> # this is a comment \
> echo "work !!"
>
> the bash or the bourne shell ignore \ on the comment line !
Remember though that the hosts.{deny,allow} files are not shell scripts.
You cannot assume the syntax rules for one apply to the other, or vice
versa.
Indeed many programs which implement "line continuation" syntax similar
to the "\<newline>" feature will suffer the same problem, including GNU
Make (and probably other makes, but not BSD make).
It's interesting to note that the line continuation feature is *NOT*
documented in the hosts_access(5) manual page. Unless you've read the
source you shouldn't even know that you can use "\<newline>" to continue
a long entry onto the next line! ;-) [[ There is one hint in an
example. ]]
Of course if you read a bit more of the code you'll find that the
stripping of "\<newline>" is done before the check for comment
characters.
There is another even nastier undocumented "limitation" to TCP Wrappers
configuration files -- the maximum length of any "line", whether it is
split by "\<newline>" continuations or not, is BUFLEN-1, which is
normally 2047 bytes.
Futhermore you'll find that TCP Wrappers counts "lines" after the
continuations have been stripped too, which implies that if you use
continuations you'll have a much harder time finding the entry which
tcpdmatch (for example) claimes to have found.
In the end I've found it's more useful to split entries onto multiple
lines anyway (one per target host or network) and to never use
continuations -- which works just fine -- because it has the added
benefit of making it easier to debug which hostname or IP# matched
(tcpdmatch and verbose logging show the line number, and "line numbers"
reported match those my text editor knows about. This also means I'm
not using an undocumented feature! ;-)
(BTW, I think your English was more than adequate enough to get your
point across!)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoodsat_private> <robohack!woods>
Planix, Inc. <woodsat_private>; Secrets of the Weird <woodsat_private>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:22 PDT