Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 26385 - Bizarre behavior of /etc/ftphosts
Bizarre behavior of /etc/ftphosts
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: wu-ftpd (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-06 19:56 EST by Christian Lepine
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-12 17:32:49 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 Christian Lepine 2001-02-06 19:56:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [fr] (X11; U; Linux 2.2.16-22 i686)


The man page of ftphosts says that when I use deny username addrglob, hosts
maching addrglob logging in as username will be deny.
Actually, the username is always deny even if he is from another addrglob.
I have try :
deny tux 192.168.1.100

and

deny tux *.maison

And I always get a deny even if the user tux is comming from another
address or domain ???? 


Reproducible: Always
Steps to Reproduce:
1. enter a deny directive for a user maching an address in /etc/ftphosts
(deny tux 192.168.1.100)
2. Try to connect from another address but with that username (ncftp -u tux
ftp.maison) note that the client address is not 192.168.100.
	

Actual Results:  It won't connect

Expected Results:  The user tux is not comming from address 192.168.1.100
so he should be able to connect
Comment 1 Karsten Hopp 2001-02-07 09:32:01 EST
verified even with IPs of xx.xx.xx.xx/mask. Regardless of the IP, the access
for this user will be denied. (wu-ftpd-2.6.1-12)
Comment 2 Bernhard Rosenkraenzer 2001-02-07 09:37:13 EST
Yes, wu-ftpd's algorithm for determining these things is ultimately broken
and needs a rewrite. pHtmp is ALWAYS NULL if a matching entry is found
but does not apply.
I'll fix this later today.
Comment 3 WU-FTPD Development Group 2001-03-12 17:32:46 EST
Index: doc/ftphosts.5
===================================================================
RCS file: /cvsroot/wu-ftpd/doc/ftphosts.5,v
retrieving revision 1.6
diff -r1.6 ftphosts.5
41a42,52
> 
> NOTE VERY CAREFULLY:
> 
> The last rule which matches is the default rule.  So, to allow a user to login
> from anywhere _except_ the listed hosts, you need both allow and deny rules.
> The following example denies the user hacked from logging in from the host
> 10.1.2.3, but allows login from all other hosts.
> 
> deny hacked 10.1.2.3
> allow hacked *


Please close this ricket.

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