Bug 34817 - !! xinetd starts ftpd when man page says it WON'T !!
Summary: !! xinetd starts ftpd when man page says it WON'T !!
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-05 05:31 UTC by Need Real Name
Modified: 2007-03-27 03:43 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-05 18:43:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-04-05 05:31:24 UTC

   I have just freshly installed redhat 7.1 re i386 iso
   I've used linux on and off since 91 or 92.

   xinetd has a naughty ftpd problem which [is not] yet 
   in any problem report.

   xinetd's man page states, for "/etc/xinetd.d/*",
   if disable == yes for a service
   that xinetd, when a request for that service on
   the port arrives, WILL REFUSE the connection.
   HOWEVER - xinetd DOES START ftpd on port 23
   despite its flatulent claim!
   (no, no ftpd daemon is or was loaded)

I have read the man page.  It is wrong: that is 
an error that needs attention.

xinetd shouldn't launch services on ports it has 
"no configured knowledge of"; as per manpage exposition.

Infact - inetd (Linux NetKit 0.17) has been tried and 
tested.  However:

xinetd has had at least 5 fixes already. xinetd wasn't
initially linuxconf ready (and so valuable linuxconf
contributor time was spent 'fixing it):

I'm wondering just how xinetd got chosen as a viable
unix base system solution.  It just isn't all that:
the author didn't even claim it to be.

Why the name change that breaks scripts (that steer 
inetd)?  Why change the well known super-server fields
in the config file - which up until now have been similar 
across platforms?

Will the linuxconf "fix" that made \[Xi]netd actually work
keep me from using the inetd from:
        "Linux NetKit 0.17"
with redhat?  If it does - I'm telling!  (Or, I'll just not
be as happy as I would normally be.)

Thanks, hope that helps,

    John D. Hendrickson




   This is like strike six for xinetd, right?  How many
   strikes does it get anyway?  

   Is an imperfect kerberos implementation really important?  

   Kerberos doesn't have three heads -- it has 100 
   configuration sides.  I mean, an NIS+ configured subnet 
   with stunnel-only connects is good too -- and offers the 
   same opertunity for password upgrade binges, host-host 
   tunneling, secure administration, etc...

   And anyway?  If kerberos is so great, how come they're
   "begging" it be exported?

   Ok - maybe I'm out of my realm on the encrypted 
   configurable network point.  Still - stunnel is easier
   and doesn't require application re-writes for transport
   independant (unix) apps, and Kerberos does (kerberiz#q*^&)  

   Anyway, Have a good one..

Comment 1 Bill Nottingham 2001-04-05 18:43:55 UTC
ftpd doesn't listen on port 23. Are you sure that's what you're seeing?

Comment 2 Trond Eivind Glomsrxd 2001-04-06 16:02:15 UTC
Actually, I'm sure he didn't. Also, he claims to have installed RHL 7.1 from
isos - and I now that disable works. This is a bogus report.

Note You need to log in before you can comment on or make changes to this bug.