All mail regarding bugs in the Debian system is copied to this mailing list

Edward Welbourne | 18 Aug 2012 11:23

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

(Continue reading)

headers

Marco d'Itri | 18 Aug 2012 14:05

Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format

On Aug 18, Edward Welbourne <eddy <at> 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

headers

Edward Welbourne | 18 Aug 2012 17:35

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.

(Continue reading)

headers

Marco d'Itri | 19 Aug 2012 00:12

Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format

On Aug 18, Edward Welbourne <eddy <at> 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.

(Continue reading)