Bug 19957 - wu-ftpd server runs even when `disable = yes' keywords present in xinetd.d entry
wu-ftpd server runs even when `disable = yes' keywords present in xinetd.d entry
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-28 13:10 EDT by theenglishman
Modified: 2007-03-26 23:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-15 13:49:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description theenglishman 2000-10-28 13:10:03 EDT
The wu-ftpd server still runs when an ftp request is made, even although
the file /etc/xinetd.d/wu-ftpd has the following line:

disable = yes

which is placed in /etc/xinetd.d/wu-ftpd by disabling wu-ftpd using the
"setup" tool.
 Even if xinetd is sent a -HUP signal, wu-ftpd continues to respond to ftp
requests.

This happens if the ftp connection is from localhost or from a remote
machine.

 My system is a clean install RH7 on a i686, with some services shutdown
(sendmail, nfs etc).
Comment 1 Trond Eivind Glomsrxd 2000-10-29 22:40:53 EST
So you changed this setting, and it continued to respond? (not the same as
"respond if disable=yes")
Comment 2 theenglishman 2000-10-30 05:00:16 EST
I changed the line manually to disable = no and it responds to ftp requests - as
expected.
Maybe I'm reading man xinetd.conf wrong, but as far as I can see, disable = yes
should override anything else and shut the service down.

 Maybe tcpserver from http://cr.yp.to/ should be included with RH7.1?
Comment 3 Rob Braun 2000-11-15 13:05:14 EST
My interpretation of this is that you've modified the
config file, kill -HUP'd xinetd, and your changes have
not taken effect.  

If this is in fact the case, it should not work.  As
documented in the xinetd man page, a SIGHUP has xinetd
dump it's debugging information.  What you want is a
SIGUSR2 to reconfigure xinetd.
Comment 4 Trond Eivind Glomsrxd 2000-11-15 13:49:15 EST
That's what's used in "service xinetd reload".
Comment 5 theenglishman 2000-11-16 04:11:05 EST
Mmmm. OK, seems a bit wierd not to use a SIGHUP for reconfig, but I guess I
should have RTFM'd a bit more.
Guess this is resolved then - changing to not a bug.
Cheers.

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