Bug 89765 - vsftpd doesn't work (mostly) with tcp wrappers
Summary: vsftpd doesn't work (mostly) with tcp wrappers
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vsftpd (Show other bugs)
(Show other bugs)
Version: 9
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Mike McLean
Keywords: Security
: 88768 89766 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-27 23:13 UTC by Dale Stimson
Modified: 2014-03-17 02:35 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-28 15:53:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A version of tcpwrap.c that has fixes for this bug and works for me. (861 bytes, text/plain)
2003-04-27 23:15 UTC, Dale Stimson
no flags Details

Description Dale Stimson 2003-04-27 23:13:10 UTC
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 Dale Stimson 2003-04-27 23:15:29 UTC
Created attachment 91323 [details]
A version of tcpwrap.c that has fixes for this bug and works for me.

Comment 2 Bill Nottingham 2003-04-28 15:47:02 UTC
*** Bug 89766 has been marked as a duplicate of this bug. ***

Comment 3 Bill Nottingham 2003-04-28 15:53:30 UTC
Added, will be in 1.1.3-9 - thanks!

Comment 4 Bill Nottingham 2003-04-28 15:54:09 UTC
*** Bug 88768 has been marked as a duplicate of this bug. ***

Comment 5 Alan Sanderson 2003-11-17 02:00:58 UTC
vsftpd 1.2.1 has just been released and addresses this problem.
Perhaps vsftpd should be updated to 1.2.1 in devel.

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