Package: libwrap0
Version: 7.6.q-23
Severity: normal
Dear Debian Maintainer,
I tried to configure /etc/hosts.{allow,deny} using what man pages told
me; hosts.allow and hosts.deny alias to hosts_access in man. This told
me I could use lines of form
daemon_list : client_list [ : shell_command ]
but, in fact, I got errors logged by sshd when I used this format, due
to sshd actually using the format described in man hosts_options
daemon_list : client_list : option : option ...
(which should clearly be written as
daemon_list : client_list [ : option ...]
or similar, since options are optional). It was not immediately clear
what sshd was complaining about, of course - I only found out this was
the problem after writing to Wietse Venema for help ! - but once I'd got
the right information it was indeed possible to get what I wanted.
I thus find the man pages to be somewhat confusing - the one I get
naturally tells me a format that isn't actually supported; it does tell
me there's an extended version of the language, but doesn't make clear
that this is what's actually in use. I initially used
ALL : ALL : /usr/bin/logger -p auth.warning -- 'Denied %c (%n) access to %d on
%r'
in my hosts.deny but got error messages which didn't really (given only
the hosts_access man page's content) help me to make sense of what the
error really was; everything in the man page fitted with this being a
valid line to include. Changing to
ALL : ALL : severity auth.warning
did solve the problem. The hosts_access man page did say that
hosts_options supersedes shell_command support; but I, at least, failed
to recognise this as a clue that this was why my shell command wasn't
being recognised.
Further, given that the two syntaxes are incompatible, everything I can
see tells me that reading of /etc/hosts.{allow,deny} is up to each
application independently, so I have no way (as administrator of my box)
to know how I can avoid problems with my setup if some applications
choose to support the hosts_access format instead of the hosts_options
format. Likewise, an application developer has no indication of which
format they should support, to be compatible with configurations
administrators are apt to set up, or of how they should avoid getting
into trouble if the administrator has used the other format than the one
they've chosen to parse.
I can (now that I've tracked down what supplied these man pages) make an
educated guess that libwrap0 provides a library that deals with the
parsing on behalf of applications, but neither man page advises
application developers to use it, nor even mentions the existence of
such a library - as they clearly should. There should be a man page for
the APIs provided by the library and it should be referenced by the man
pages reached by "man hosts.{allow,deny}", since that's where a
developer is apt to start trying to find out how to honour the system
configuration specified in these files.
Given that the "extended" format is now (apparently) what's supported by
default (in particular, it's what sshd expects - developers of other
applications are particularly likely to take their lead from sshd), it
seems to me that it would make sense to amalgamate the two man pages and
either remove all mention of the shell_command syntax or relegate it to
a historical / backwards-compatibility section, with advice on what to
do with files using this syntax, if encountered. The format now in
normal use should no longer be described as "extended".
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages libwrap0:amd64 depends on:
ii libc6 2.13-33
ii multiarch-support 2.13-33
Versions of packages libwrap0:amd64 recommends:
ii tcpd 7.6.q-23
libwrap0:amd64 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
