Bug 89766

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.