[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: