Bug 89765 - vsftpd doesn't work (mostly) with tcp wrappers
vsftpd doesn't work (mostly) with tcp wrappers
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: vsftpd (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Mike McLean
: Security
: 88768 89766 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-27 19:13 EDT by Dale Stimson
Modified: 2014-03-16 22:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-28 11:53:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 19:15 EDT, Dale Stimson
no flags Details

  None (edit)
Description Dale Stimson 2003-04-27 19:13:10 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):
vsftpd-1.1.3-8
Also, FWIW, tcp_wrappers-7.6-34

How reproducible:

Always

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:
vsftpd: 192.168.123.1

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 2.168.101.1: connected: warning: can't get client
address ...
[Note that "amd" is the system name, not to be confused with the daemon".  The
text string
"2.168.101.1: 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 19:15:29 EDT
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 11:47:02 EDT
*** Bug 89766 has been marked as a duplicate of this bug. ***
Comment 3 Bill Nottingham 2003-04-28 11:53:30 EDT
Added, will be in 1.1.3-9 - thanks!
Comment 4 Bill Nottingham 2003-04-28 11:54:09 EDT
*** Bug 88768 has been marked as a duplicate of this bug. ***
Comment 5 Alan Sanderson 2003-11-16 21:00:58 EST
vsftpd 1.2.1 has just been released and addresses this problem.
ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-1.2.1/Changelog
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.