SOLVED! Was: (Re: xinetd and fetchmail)
* Me <r.a.jacobs@home.com> [221100 12:12]:
> Debian Users,
>
> I'm trying to be security conscious. I've heard xinetd is the way to
> go when it comes to an internet super-server so I apt-get installed it. Only
> problem is that I can't get it to work with fetchmail.
>
> My xinetd.conf only contains one stanza. Here it is:
>
>
> service smtp
> {
> socket_type = stream
> protocol = tcp
> wait = no
> user = mail
> server = /usr/sbin/exim
> server_args = -bs
> }
>
>
> My inetd.conf file, before I began trying to use xinetd, only had one
> entry in it. It was:
>
>
> smtp stream tcp nowait mail /usr/sbin/exim exim -bs
>
>
> Fetchmail operates fine with inetd. However, whenever I attempt to run
> Fetchmail under xinetd, this is the error I get:
>
>
> 16 messages for r.a.jacobs at mail (195121 octets).
> reading message 1 of 16 (4048 octets) ..fetchmail:SMTP connect
> to localhost failed
> fetchmail: SMTP transaction error while fetching from mail
> fetchmail: Query Status=10 (smtp)
>
>
> So...why won't xinetd allow me to fetch my mail? Does this have
> anything to do with RPC and how do I fix it?
>
> Your help is greatly appreciated,
>
> robert <r.a.jacobs@home.com>
> ~no witty sig required~
After a lot of swapping back and forth between inetd and xinetd and a lot of
reading on xinetd, I was finally able to solve this problem thanks to a
tidbit in the article "What's that, xinetd?" by Frederic Raynal.
You can find this article referenced on http://www.xinetd.org homepage or go
directly to http://www.linuxfocus.org/English/November2000/article175.shtml
At the bottom of the "Starting with a Riddle" section, Mr. Raynal provides the
following warning about combing tcp_wrappers type security (via inetd) and
security the way xinetd handles it.
(This is a direct quote -- Mr. Raynal is French...so his English is not
perfect...but I'm sure you'll get the meaning)
"...Since the request is accepted by xinetd, it's sent to the specified
server (here tcpd). Nevertheless, tcpd rejects this connection. Then, we
must have a look at hosts.{allow,deny}. The /etc/hosts.deny file only
contains ALL:ALL@ALL, what explains why the request has been rejected by
the wrapper!
According to the way the server and server_args service lines have been
defined, the wrapper features are still accessible (banner - there's a
banner attribute in xinetd-, spawn, twist, ...). Remember that the
--with-libwrap compilation option only adds access rights control (with
the help of hosts.{allow,deny} files), before xinetd process starts. In
this example we saw that this configuration allows us to continue using
the tcp wrapper features.
This overlapping of features, if it can work, may as well lead to stange
behaviors. To use xinetd together with inetd and portmap, it's much
better to manage a service with only one of these "super-daemons".
As soon as I turned off the ALL:ALL entry in my /etc/hosts.deny file, my
problem disappeared. For the meantime, until I read a little more on xinetd,
I'm going to continue using inetd. Hopefully, within a few days, I'll be up
on xinetd.
Here's a summary of my "journey" with this problem -- (if you care to see it):
=============================================================================
Problem: Fetchmail refused to get my mail after installing xinetd in place
of inetd
Analysis: Running "nmap -v localhost" and "rcpinfo -u localhost portmap"
showed that when inetd was in control the portmapper was
active, ready and waiting. However, when xinetd was in
control, the portmapper was not available.
"nmap -v localhost" for inetd contained an entry for
sunrpc while xinetd did not. Both super-servers contained
entries for smtp.
Actions: I compared the output of nmap for each superserver.
I compared the output of rcpinfo for each superserver.
I compared the output of running inetd with the
portmapper disabled to running xinetd as is and saw
that the results were the same.
I tried turning the portmapper on (/etc/init.d/portmap start)
while xinetd was running but it failed anyways.
I tried changing the xidentd script in /etc/init.d/ to mirror
the inetd script, replacing direct references to inetd with
xinetd (I was getting desperate! :) )
I read a LOT on xinetd.
Solution: Remove the ALL:ALL entry from /etc/hosts.deny
Reason: Not quite sure (can anyone explain?) but xinetd and inetd
do not like to play together in the area of security. Has
something to do with the --with-libwrap compilation
configuration argument.
Anyways, that's my story...hope it helps someone else out there!
rob jacobs (r.a.jacobs@home.com)
~no witty sig required~
Reply to: