On a very very very rare number of occasions, we have seen an OOPS of this form:

500 OOPS: cannot open config file:/etc/vsftpd/vsftpd.conf.localhost

when all the file permissions are seemingly correct. This was seen when using
the tcp_wrappers env option VSFTPD_LOAD_CONF to load a secondary configuration
file above and beyond /etc/vsftpd/vsftpd.conf.

The result - on one occasion - was that vsftpd effectively refused ALL new
connection attempts, always returning the same OOPS. Restarting vsftpd worked
round the problem. No error logs of any kind - other than the OOPS on the FTP
control connection - were seen.


Hunting round the source code for explanations, I found that the RedHat version
of vsftpd used this line in parseconf.c:

(int)str_stat(&config_file_str, &p_statbuf);

It appears that &config_file_str ACTUALLY contains a string containing the
CONTENTS of the configuration file, rather than the filename itself.

My supposition is that this is the more correct function to use:

(int)vsf_sysutil_stat(p_filename, &p_statbuf);

The invocation of str_stat() is included in the "nonrootconf" patch included in
the RedHat releases, and is NOT part of vsftpd source itself.

The broken code fragment, in my view, reads like this:

  retval = str_fileread(&config_file_str, p_filename, VSFTP_CONF_FILE_MAX);
  (int)str_stat(&config_file_str, &p_statbuf);
  /* Security - die unless the conf file is owned by root */
  if (vsf_sysutil_retval_is_error(retval) ||
vsf_sysutil_statbuf_get_uid(p_statbuf) != VSFTP_ROOT_UID)
  {
    if (errs_fatal)
    {
      die2("cannot open config file:", p_filename);
    }
    else
    {
      return;
    }
  }

What seems to be happening is that the config file contents are read into
config_file_str, and then str_stat tries to use the file contents as a filename
so as to return a p_statbuf.

My reasoning is that somehow ( heaven knows how ) vsf_sysutil_statbuf_get_uid()
almost always returns zero despite being passed an invalid p_statbuf, and the
configuration file is accepted. On very very rare occasions, probably due to
subtle changes in malloc'ed memory usage, vsf_sysutil_statbuf_get_uid() returns
non-zero, and the configuration file raises an OOPS.

I've seen this explicitly on Fedora Core 4, but the source code bug - if it is a
bug - is still in the FC6 Devel tree.

I attached a revised nonrootconf patch against the FC6 v2.0.5 SRPM which uses
vsf_sysutil_stat instead.