Difference between revisions of "VsFTP"

Latest revision as of 02:54, 8 June 2007

                      linux.dbw.org Info
Info document
##############################################################################
# Some basic notes on getting your own installation of vsftpd running        #
# on Redhat 9 and Fedora Core 1.0                                            #
##############################################################################
v0.82 alpha   (which means not speeel checked or verified) 

First, make sure the vsftp server RPM has been successfully installed.
(not covered here)

Now, lets create some symlinks to make it feel more like it used to be
before it was "redhatized".

  ln -s /etc/pam.d/vsftpd /etc/pam.d/ftp
  ln -s /etc/vsftpd/vsftpd.conf /etc/vsftpd.conf
  ln -s /etc/vsftpd.ftpusers ftpusers

On some distributions including Fedora Core 1.0 it appears they try to
make vsftpd its own service.  We are going to make it an xinetd service
instead.  Remove the service script file.

  rm /etc/rc.d/rc3.d/???vsftpd

Now we will make an xinetd configuration file so that vsftpd will 
start with the other xinetd services.

  touch /etc/xinetd.d/vsftpd

Use your text editor of choice and populate the newly created vsftpd
xinetd configuration file with the following text:

  service ftp
  {
          disable = no
          flags           = REUSE
          socket_type     = stream        
          wait            = no
          user            = root
          server          = /usr/sbin/vsftpd
          log_on_failure  += USERID
  }

This assumes that your vsftpd binary is in /var/sbin.  If not, then
either move it there or create a symlink to it.

You may wish to check your hosts.allow and make sure that ftp is open
for remote connections.  Open /etc/hosts.allow in your text editor 
and ensure the following line or something workable exists:

  vsftpd : ALL

vsftpd uses the pam.d Linux authentication module.  We want to make
sure that vsftpd can find it without regards to vsftpd or distribution
version, which explains the reason for one of the symlinks above.
With your text editor open /etc/pam.d/ftp and make sure it has the
following in the configuration: (which it should by default)

  auth       required     /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
  auth       required     /lib/security/pam_pwdb.so shadow nullok
  auth       required     /lib/security/pam_shells.so
  account    required     /lib/security/pam_pwdb.so
  session    required     /lib/security/pam_pwdb.so

vsftpd uses a configuration file of its own.  The following values are 
recommended for use in the vsftpd.conf file.  Use your text editor and modify 
the /etc/vsftpd.conf file.

  anonymous_enable=YES
  local_enable=YES
  write_enable=YES
  local_umask=022
  anon_upload_enable=NO
  dirmessage_enable=YES
  xferlog_enable=YES
  connect_from_port_20=YES
  nopriv_user=nopriv
  ftpd_banner=You are visiting a fine FTP server.

A non-privileged user shall be created for your system and must exist in the
passwd file.  We chose 'nopriv' as you can see above.  However, it can be any
name you wish as long as it is not in use, and matches the vsftpd configuration
file as well as the passwd file.

It is recommended you create your nopriv user with uid 97 and the shell
/sbin/nologin or /bin/false.  example line from /etc/passwd:

  nopriv:x:97:97::/home/ftp:/sbin/nologin

You are not going to want a user named 'nopriv' attempting to connect to your
ftp server as well as using other reserved system names.  With your  text 
editor open the file /etc/ftpusers for editing.  Here is a sample of what 
you may wish to have in the file:

  root
  bin
  daemon
  adm
  lp
  sync
  halt
  mail
  news
  uucp
  operator
  games
  gopher
  ftp
  squid
  mysql
  rpc
  rpm
  ntp
  gdm
  xfs
  pcap
  ident
  nobody
  nopriv

Check your /etc/shells file and make sure the correct entries exist (all of 
the allowed system shells).  Add an entry called '/bin/true'.  Here is a 
sample of a valid /etc/shells file:

  /bin/sh
  /bin/bash
  /sbin/nologin
  /bin/bash2
  /bin/ash
  /bin/bsh
  /bin/tcsh
  /bin/csh
  /bin/ksh
  /bin/zsh
  /bin/true

The entry /sbin/nologin and /bin/true service the same purpose, to allow people
ftp access without shell access.  However, /sbin/nologin is someting Redhat 
now gives us while /bin/true is perhaps the traditional linux geek's method.
A dummy /bin/true might be necessary, try 'touch /bin/true' or make it +x if
you problems using this as a shell in the passwd file.  You could also make a
symlink to /sbin/nologin.

It is preferred to have the ftp root under /home rather than /var but out of
habbit a lot of sysadmin's will look in /var/ftp. So the following is 
recommended:

  mv /var/ftp /home
  ln -s /home/ftp /var/ftp
  mkdir /home/ftp/upload
  mkdir /home/ftp/pub

Hopefully we haven't missed anything important.  Now you are ready to start 
the ftp server.  If xinetd is already running, restart it, otherwise start the
xinetd service with the following command:

  service xinetd start

A BRIEF EXPLANATION OF SYSTEM USERS
(who has shell access, ftp access, and email access)

Some common combinations of non-privileged system user access are as follows:

  1. A user has pop3, ftp, and shell access (such as telnet or ssh)
  2. A user has pop3, and ftp access only
  3. A user has only pop3 access

This is controlled by the /etc/passwd file shell entry for each user.  Now to
match up a passwd entry for our user 'johnd' with the examples above:

  1. johnd:x:500:100:John Doe,,,,:/home/johnd:/bin/bash
  2. johnd:x:500:100:John Doe,,,,:/home/johnd:/bin/true
  3. johnd:x:500:100:John Doe,,,,:/home/johnd:/bin/false

The shell /bin/bash allows johnd shell access because not only is /bin/bash a
valid shell as stated in /etc/shells, but it really is a valid shell command
environment as long as the Bourne Again Shell is installed on the system.

While /bin/true is also a valid shell defined in /etc/shells, it is not a real
command environment.  This prevents remote shell access via ssh or telnet, 
while still allowing ftp access for the user to his or her home directory.

Finally, since /bin/false is not even mentioned in /etc/shells it pretty much
is not a valid shell by any sence.  Most xinetd pop3 daemon servers will still
allow pop3 user authentication, however, vsftpd will not.

Thank you for taking the time to utilize or read this FAQ document.  Although
not full of "why" it has plenty of "how" and thus puts you on the road to 
making it work and terms to go search for if you intend to learn more.

  -------------------------
  Permissions: local_umask
  -------------------------

This new section deals specifically with the file permissions set on files
uploaded by FTP users with an account in passwd.    

By default, vsftpd has system users write files as user + group from passwd
with the permissions 0644 or rw-r--r--
  6 = read + write for the user
  4 = read for the group
  4 = read for world

The parameter to change the default permission is 'local_umask'.  This works
like UNIX umask.  If file_open_mode=0777 then a local_umask=000 gives file
permissions of rwxrwxrwx or 0777.  If file_open_mode=0777 then a 
local_umask=0022 guves file permissions of rwxr-xr-x or 0755.  It works by
simple subtraction independent for each column of digits.

           0 7 7 7
  umask -  0 0 2 2
  ----------------
           0 7 5 5

coveats:  Technically the default for vsftpd strictly was local_umask=022
which worked even though a digit shy.  However, when trying to change it, 
three digits are read as decimal instead of octal.  To achieve the desired
effect it is necessary to set the file_open_mode=0777, because if you don't
vsftpd will use a default of file_open_mode=0666.

Working Example:

I have a web server where I want individuals with an account on the system 
to all be able to work on the default web site.  I wish to have a group 
where all members can delete, create and replace files and directories.
The following settings are necessary in vsftpd.conf

local_enable=YES
local_umask=0003
file_open_mode=0777

Now all files uploaded will be:  rwxrwxr-- or 0774

However, when another user replaces files originally created by the first
user, the first user retains ownership.  If you prefer a configuration where
the replaced file takes on the ownership of the new user, you can use the
settings in the below.  It will prevent actual file replacement, so the new
user will have to delete the original user file and then upload the new
file of the same name.  One drawback is that files in a subdirectory can 
only be deleted by the original user due to the way permissions work on a
directory.  There is no local_dmask option!

local_enable=YES
local_umask=0022
file_open_mode=0755

Now all files uploaded will be:  rwxr-xr-x or 0755
* files in subdirectories may not be deleted by the new user.


-Derek Winterstien

created:
Wed Apr 21 22:31:44 CDT 2004

last modified:
Mon Feb 12 15:29:36 CST 2007