VsFTP
From Free Knowledge Base- The DUCK Project: information for everyone
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
