I have an Ubuntu server that's currently hosting a WordPress site using an Apache web server, MySQL and PHP etc. Additionally I have configured VSFTPD and SSH to handle FTPS (implicit FTPS) and SFTP and I have created two accounts foo and bar for example. My web server is running under the www-data Unix user/group which I can see using the following command: sudo apachectl -S

User: name="www-data" id=33
Group: name="www-data" id=33

sudo ps -aux | egrep apache2 '(httpd|apache2|apache)' confirms this too.

The two user accounts foo and bar, foo is part of the sudo group and bar is a standard user. 

Following WordPress' hardening guide Changing file permissions found here

"Typically, all files should be owned by your user (ftp) account on your web server, and should be writable by that account. On shared hosts, files should never be owned by the webserver process itself (sometimes this is www, or apache, or nobody user). Any file that needs write access from WordPress should be owned or group-owned by the user account used by WordPress (which may be different than the server account). For example, you may have a user account that lets you FTP files back and forth to your server, but your server itself may run using a separate user, in a separate usergroup, such as dhapache or nobody. If WordPress is running as the FTP account, that account needs to have write access, i.e., be the owner of the files, or belong to a group that has write access. In the latter case, that would mean permissions are set more permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644)."

With that in mind, I have added foo as the owner and www-data as the group owner of the web root directory at /var/www/example.com using the following command:

sudo chown -R foo:www-data /var/www/example.com

I then set the file and directory permissions as detailed in the WordPress permissions guide using the following commands:

# Set permissions for directories
find "/var/www/example.com/" -type d -exec chmod 775 {} \;

# Set permissions for files
find "/var/www/example.com/" -type f -exec chmod 664 {} \;

# Set permission for 'wp-config.php' file
sudo chmod 440 "var/www/example.com/wp-config.php"

# Set all permissions on all 'htaccess' files
sudo chmod 664 "/var/www/example.com/.htaccess" "var/www/example.com/wp-admin/.htaccess"

When the foo user is accessing /var/www/example.com via SFTP or FTPS they are able to delete files, make new files and change permissions as expected being the owner.

This is fine if you only need one user to be able to edit files via FTP. However, in my case I need to enable full permissions to bar so they can fully edit files/directories too. From my understanding of Unix permissions, the way for multiple users to have full permissions on files/directories would be to add both users to a group and set the group owner to that group. For example:

sudo usermod -a -G www-data foo
sudo usermod -a -G www-data bar

# Re-set permissions on web root directory
find /var/www/example.com/ -type d -exec chmod 775 {} \;
find /var/www/example.com/ -type f -exec chmod 664 {} \;

However, to be able to give full permissions to foo and bar in the www-data group they would require their file permissions to be updated to 674 find /var/www/example.com/ -type f -exec chmod 674 {} \;?

This however breaks away from the recommended secure permissions WordPress have defined for files and directories. What I'm trying to understand and the questions I'm trying to ask are:-

  1. Can I set owner to www-data and set foo as the group owner?
  2. Can I lower the permissions for the new owner and heighten the permissions for the new group owner?

In other words I'm swapping the owner and group owners around. Essentially the process in which the Apache web server is running (www-data) and the new owner of the web root directory would become the same account. What are the security implications of having the owner of the web root directories files/directories the same as the web server user it's running under?

1 Answer 1


It sounds like you've got a pretty good understanding of what the implications are. The goal of security recommandations is to give the lowest amount of permissions that allow your system to be maintained so that no data is needlessly exposed to reads or updates. The recommandations you're referring to try to give you a configuration that is best in most cases but might not be ideal in yours.

In this specific case, I'd advise against using group permissions to handle file accesses: it would also mean changing the umask used by vsftpd (-> might have side-effects if other users connect to other folders on your server) as well as default groups for your users and will be a pain to handle in the long run if you have to add an other user for example.

What you probably want to do instead is set-up user-specific (or global if they are your only ftp users) configuration in vsftpd to map both users to a third one when they access the server. By doing this, you can handle the permissions in your folder as if there is only one user accessing it (the new user).

Take a look at user_config_dir in VSFTD's MAN pages to set-up the directory as well as guest_username for the user mapping

  • Does OpenSSH have anything similar to this? SFTP is FTP over SSH and I primarily use SFTP over VSFTPD where I can. Jan 25, 2021 at 12:12
  • I have never had to set-up such a thing for SSH. There might be a way with tunneling, but I would probably just grant the specific users I want to be able to access and the user with permissions on the directory a common group with a known common folder where they could share files and grant members of the group permission to execute sudo su <common_user> :/ It's clunky, but I don't know how to set-up something similar with SSH (or if it's possible) ; maybe wait for someone else to come.
    – cg_foreau
    Jan 25, 2021 at 13:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.