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 89766 - vsftpd doesn't work (mostly) with tcp wrappers
vsftpd doesn't work (mostly) with tcp wrappers
Status: CLOSED DUPLICATE of bug 89765
Product: Red Hat Linux
Classification: Retired
Component: vsftpd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Mike McLean
: Security
Depends On:
  Show dependency treegraph
Reported: 2003-04-27 19:34 EDT by Dale Stimson
Modified: 2014-03-16 22:35 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:52:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dale Stimson 2003-04-27 19:34:33 EDT
Description of problem:

vsftpd, when tcp wrapper usage is enabled, is not only generating a log message
as reported in bug 88768, but is in fact not working with tcp wrappers.

Version-Release number of selected component (if applicable):
Also, FWIW, tcp_wrappers-7.6-34

How reproducible:


Steps to Reproduce:
1.  Setup /etc/hosts.allow and /etc/hosts.deny so that a particular IP address
will be rejected.  For example, in /etc/hosts.deny, add the line:

2.  Attempt ftp access from the test IP address.

Actual results:

Access is allowed.

Expected results:

Access should not be allowed.

Additional info:

A suggested revised version of tcpwrap.c will be attached to this bug report. 
This works for me.

The problem is in vsftpd file tcpwrap.c.  It calls tcp_wrapper's request_init,
but does not specify a file descriptor.  It then calls function tcp_wrapper's
function fromhost, with the intention that fromhost will determine the IP
address, etc., of the client.  Because the file descriptor has never been set,
tcp_wrapper's initialization file descriptor value of -1 is used in its function
sock_host in a call to getpeername.  That call (and associated code) ultimately
issue an error message that says "warning: can't get client address: Bad file
descriptor" that  is issued  via syslog (and ends up in /var/log/messages). 

Since no client address was ever detemined, IP based access controls fail.

Suggested solution:  Add "RQ_FILE, 0," into the variable parameter list of
tcpwrap.c's call to function request_init to specify that the socket is open on
file descriptor 0.  (It would be nicer to get the file descriptor number from a
variable or symbol, of course).

Related issue:  tcp_wrapper ultimately issues the "can't get client address" via
a call to vsyslog.  However, function openlog has never been called.  Although
the call to openlog is documented as "optional", with its parameter "ident"
defaulting to NULL, what really happens is that ident
does not default as it should and therefore uninitialized data is used for the
ident field of the syslog message.  Sample log line from /var/log/messages:
    Apr 27 10:38:24 amd connected: warning: can't get client
address ...
[Note that "amd" is the system name, not to be confused with the daemon".  The
text string
" connected:" is just garbage. 

Conclusion: tcpwrap.c should have a call to openlog so that tcp_wrapper syslog
messages are properly identified as coming from vsftpd.  The default is that the
open of the log will not be done in the call to openlog, but will wait until a
message is actually issued.  This should make the call to openlog fairly
lightweight for the normal case.
Comment 1 Bill Nottingham 2003-04-28 11:46:54 EDT

*** This bug has been marked as a duplicate of 89765 ***
Comment 2 Red Hat Bugzilla 2006-02-21 13:52:50 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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