Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format
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
Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format
On Aug 18, Edward Welbourne e...@chaos.org.uk wrote:
The current documentation has worked well enough for the past 15-20
years or so, but if you really believe that younger sysadmins may be as
confused as you are then please send me a patch for hosts_access(5)
which removes references to the old syntax.
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
You are seriously misunderstanding how libwrap works: it is a library,
and it parses the hosts files by itself.
So maybe you will just want to close this bug instead.
--
ciao,
Marco
signature.asc
Description: Digital signature
Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format
The current documentation has worked well enough for the past 15-20
years or so, but if you really believe that younger sysadmins ...
Hmm ... I think you're assuming that only sysadmins ever need to know
how to secure a computer. I think that every user of Linux is their own
acting sysadmin and, like myself, has no training in sysadmining. If
Linux is to actually be usable by the masses, we need to make it
practical for ordinary users to ensure their machines are suitably
secure. Being able to configure /etc/hosts.{allow,deny} is a proper
part of that. If explained properly, it's simple enough that users have
a fair chance at that; but the present man pages serve a new-comer
poorly.
please send me a patch for hosts_access(5) which removes references to
the old syntax.
I may give that a go - but, to do so, I'll need answers to:
* What are the man pages for libwrap's APIs ? The man pages for
hosts.{allow,deny} should reference these.
* Is it known that nothing still supports the old syntax ? I certainly
don't know. What was the actual history, and is it actually correct
to leave no mention of it ? When was it supported, on what systems,
and what incompatibilities may one encounter by failing to consider
the old syntax ?
The former should be referenced from the hosts_access(5) page; the
latter are matters that should be taken into account when deciding
whether to drop all mention of the old syntax or to include advice on
how to upgrade from it.
You are seriously misunderstanding how libwrap works: it is a library,
and it parses the hosts files by itself.
With due respect, I believe you are seriously misunderstanding my bug
report, a major part of which is that man hosts.{allow,deny} doesn't
give any clue that there's a library to parse these files. You don't
even seem to have noticed that I worked this out (albeit by guesswork
based on the package name, subsequently confirmed by looking at the
package's contents) !
Someone previously ignorant of how hosts.{allow,deny} work shall
naturally type man hosts.allow or man hosts.deny; and the information
they'll get is, frankly, misleading and incomplete. It describes an
out-of-date format for the files and fails to give any clue to the
existence of a library that implements proper support.
I am compelled to wonder how many applications that should be using this
library don't and, in practice, ignore anything but the first two fields
of hosts.{allow,deny} lines, since their authors got confused guidance,
on how to parse anything after that, from the documentation they
properly consulted to find out what to support.
Eddy.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format
On Aug 18, Edward Welbourne e...@chaos.org.uk wrote:
The current documentation has worked well enough for the past 15-20
years or so, but if you really believe that younger sysadmins ...
Hmm ... I think you're assuming that only sysadmins ever need to know
I am not interested in arguing over definitions, but tcp-wrappers for
better or for worse was never designed as a tool for the masses and you
need to consider the target audience when thinking about improving its
documentation.
please send me a patch for hosts_access(5) which removes references to
the old syntax.
I may give that a go - but, to do so, I'll need answers to:
* What are the man pages for libwrap's APIs ? The man pages for
You can easily find a list by looking at the files installed by the -dev
package, but this does not really matter since this is an implementation
detail.
hosts.{allow,deny} should reference these.
No, they do not, and I have not suggested major changes to the
documentation.
* Is it known that nothing still supports the old syntax ? I certainly
Again, nothing but libwrap parses the hosts files.
I am compelled to wonder how many applications that should be using this
library don't and, in practice, ignore anything but the first two fields
of hosts.{allow,deny} lines, since their authors got confused guidance,
Again, nothing but libwrap parses the hosts files.
--
ciao,
Marco
signature.asc
Description: Digital signature
