I'd recommend setting it to be owned by james:james
.
Alternatively, you could leave it as root:root
and requite sudo
for anybody deploying files in there, but if you are directly working in the /var/www directory (rather than working somewhere else and pushing the files there) that may not be convenient, and it won't work with FTP either.
You can set the owner of /var/www to whatever you like, as long as the www-data
user has read access. You can achieve this by setting permissions to allow world read access (as is default).
By default, it is owned by root:root
(not www-data
as you state in the question).
For security, it is not a good idea to set it to be owned by www-data
. www-data
is intended to be an unprivileged account which cannot write to any files, and can only read them.
Yes, occasionally you may need to give www-data
the permission to write to a given file, but for security this should be strictly limited to those particular files, and precautions should be taken such as making sure no such files are executable as scripts by the web server (ie they are not in a location where they may be interpreted as PHP or CGI files), etc.
For security, it is an even worse idea to set the file permissions to world-writable (eg, 777). Unprivileged users such as www-data
should not be able to write to files in this directory. The only people who need write access will be the people who are actually writing files in there.
The /var/www directory is intended to be yours to do with what you like. It makes sense to set ownership to whichever account will be editing the files. You can create a group for this purpose if you have multiple people, but in this case it's just you.
Note: if creating a group, create a new group. Do not re-use the www-data
group as that is intended to be an unprivileged group without write access to any files (as I explain above).
Too often I see people recommending adopting very bad security practices such as setting /var/www to be owned by www-data
, or adding people to the www-data
group in order to give that group editing privileges, or setting /var/www to be world-writable (eg 777). By doing any of this you are potentially opening yourself up to significant security problems.
With a bit of playing around I've managed to come up with a semi solution (not perfect but good enough)
using 2707974 answer and information I've gained else where I've been able to get what I need.
First you need vsftp and PAM installed
apt-get install vsftpd libpam-pwdfile
Edit /etc/vsftpd.conf
nano /etc/vsftpd.conf
then paste in the following
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
local_root=/var/www
chroot_local_user=YES
allow_writeable_chroot=YES
hide_ids=YES
#virutal user settings
user_config_dir=/etc/vsftpd_user_conf
guest_enable=YES
virtual_use_local_privs=YES
pam_service_name=vsftpd
nopriv_user=vsftpd
guest_username=vsftpd
Edit to your exact needs the most important bit for virtual users is everything after the virtual user settings comment
Creating User
You can either use a database or htpasswd
I found htpasswd
faster and easier to use.
make a directory to store your users
mkdir /etc/vsftpd
htpasswd -cd /etc/vsftpd/ftpd.passwd user1
adding additional users just omit the -c
htpasswd -d /etc/vsftpd/ftpd.passwd user2
I've only managed to get it to work using CRYPT which limits to 8 chars
to use more than 8 chars use openssl to generate a compatible hash and pipe directly into htpasswd
htpasswd -c -p -b /etc/vsftpd/ftpd.passwd user1 $(openssl passwd -1 -noverify password)
Once your users are created you can now change your PAM config file
nano /etc/pam.d/vsftpd
and remove everything inside this file and replace with the following
auth required pam_pwdfile.so pwdfile /etc/vsftpd/ftpd.passwd
account required pam_permit.so
This will enable login for your virtual users defined in /etc/vsftpd/ftpd.passwd
and will disable local users
Next we need to add a user for these virtual users to use. These users will not have access to the shell and will be called vsftpd
useradd --home /home/vsftpd --gid nogroup -m --shell /bin/false vsftpd
the user must match guest_username=vsftpd
in the vsftpd conf file
Defining Directory Access
The important line here is the following
user_config_dir=/etc/vsftpd_user_conf
this means that when user1
logs in it will look for the following file
/etc/vsftpd_user_conf/user1
this file the same as the vsftpd.conf
so you can define a new local_root
going back to the question we want user1
to only have access to var/www/website_name1/sub_folder1
, so we need to create the vsftpd_user_conf
folder:
mkdir /etc/vsftpd_user_conf
Now create the user file:
nano /etc/vsftpd_user_conf/user1
and enter the following line
local_root=/var/www/website_name1/sub_folder1
Now restart vsftp
service vsftpd restart
you should now be able to login as user1 who will only be able to see
var/www/website_name1/sub_folder1
and any folder and file inside it.
That's it you can now add as many users as you want and limit their access to whatever folder you wish.
important to remember if you do not create a user conf file it will default to the var/www folder as root (in the example above)
If the subfolder is intended to be modifiable by the user, it might be necesary to change the owner of the shared subfolder:
chown vsftpd:nogroup /var/www/website_name1/sub_folder1
Best Answer
You just have to modify the startup call for
vsftpd
. Theuser_config_dir
argument will tell the server to look for a configuration in the directory/etc/vsftpd_user_conf/luis
if the userluis
logs in. Analogously with any other user that logs in. I guess that if no configuration file is found the server will fallback to the default one.Anyway, take a quick read at this manual page (which you can access too from the terminal with
man vsftpd
) : http://vsftpd.beasts.org/vsftpd_conf.htmlThis other guide can help you with using custom directories for your server: http://gofedora.com/how-to-configure-secure-ftp-server-vsftpd/