On Mon, Jul 10, 2006 at 06:55:56PM +0200, Marco d'Itri wrote:
> On Jul 10, Pigeon <[EMAIL PROTECTED]> wrote:
>
> > In the case of dovecot, the daemon responding to the incoming imap
> > (or pop3) connection is named "imap-login" (or "pop3-login").
> > Therefore, unless the entries in /etc/hosts.{allow,deny} use the
> > daemon name "imap-login" instead of the obvious "imap" or "imap2" that
> > one might deduce from reading /etc/services, they will not match the
> > daemon name provided by tcpd.c.
>
> Right, I should have tought about this...
> Now I feel bad because you spent all this time working on a patch I
> cannot accept.
Don't worry, I quite enjoyed doing it :-) and it didn't significantly
affect the server setup project since there's a fair bit more still to
do on that with other stuff.
> Overloading the process name to also be a port name is
> unacceptable because it may change existing configurations.
I figured that was only likely to be a problem if it ceased to accept
the process name and only used the port name, which isn't how I've
done it. But no matter, I accept what you say.
> OTOH the feature you are proposing may be interesting, so I suggest you
> try again with a new patch which only consider port numbers and not
> symbolic names. Hopefully it will also be much less intrusive.
As in, the entries in /etc/hosts.{allow,deny} may be port numbers
instead of process names? OK, shouldn't involve much more than
taking most of the code out of my existing patch :-) I'll get onto
it later tonight.
> BTW, the correct way to work on a DBS package after unpacking it is
> like:
>
> ./debian/rules unpack
> <do stuff>
> ./debian/rules diff
>
> Then move your patch to debian/patches/ and clean+unpack again.
Thanks!
> > Now, there is much generic Linux documentation on the net that says
> > that the daemon names in /etc/hosts.{allow,deny} should correspond to
> > those in /etc/services. Certainly the dovecot wiki entry I referred to
>
> There is a lot of stupid and broken Linux documentation around.
> hosts_access(5) is very clear about this.
It is clear, but not, I suggest, so clear that it cannot be
misinterpreted.
hosts_access(5) says "_daemon_ is the process name of a network daemon
process... Network daemon process names are specified in the inetd
configuration file". As indeed they are, and are reported by ps.
However, if someone reading this doesn't fully understand it and
refers to inetd.conf(5) for clarification, they may be further confused,
as inetd.conf(5) does not name any of the fields "process name". The
relevant field is, for a tcpd-wrapped service, "server program
arguments", but the field that "looks most like" "process name" is
"service name", defined lower down as "the name of a valid service in
the file /etc/services". So if you don't read with sufficient care it
looks as if "_daemon_" ought to be a service name from /etc/services.
Perhaps this is how the writers of the aforementioned broken
documentation got confused? I'll clarify the man page and include that
in my patch.
> > But there is nothing in the Debian changelogs to indicate that support
> > for /etc/services has been removed from the Debian package for any
> > reason - no indication as to why the Debian package doesn't behave as
> > the generic, non-Debian-specific information suggests it might.
>
> Because there has never been such a behavior in the official
> tcp-wrappers package, nor I know about other distributions having
> modified it (and I check most of them from time to time).
...and as you have said above, that which suggests such a behaviour
might have been there is all wrong. Good to have that one cleared up!
--
Pigeon
Be kind to pigeons
Get my GPG key here:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
signature.asc
Description: Digital signature
