Crazy Permissions

  • Pendo

    (@msuemnig)


    8 years, 2 months ago

    I have numerous web sites hosted on an AWS Amazon Linux Lightsail VM. A couple of my customers would like access to directly make changes to their files. The majority just want me to handle everything. I’d like to add a user that my customer(s) can use, that can only read/write to their site and not even see the others. I currently do the following to set permissions on a site with this script:

    #!/bin/bash
sudo chown -R $2.www $1
sudo chmod -R 0775 $1
find $1 -type d -exec sudo chmod 0775 {} \;
find $1 -type f -exec sudo chmod 0664 {} \;
#executed at the command line like
sh script.sh /var/www/html/somesite.com apache

    That sets the owner of the files to Apache and the group to www.

    I would like to change the owner to another user and give my customer access. So I create a user following these instructions: https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance/ I use this script to assign the permissions to a user named ‘somesite’ like

    sh script.sh /var/wwww/html/somesite.com somesite

    Permissions:
    drwxrwsr-x somesite www ....somesite.com
    Which, should mean that somesite is the owner and the www group, which includes Apache, has g+w.

    Here is where the really crazy stuff starts. Using that new username+key file, I can upload media via WordPress, I can upload files via SFTP but I can’t install any plugins via the WordPress admin. WordPress prompts me to enter the FTP information, typical if you have the permissions screwed up.

    Permissions on ‘plugin’ directory is identical to ‘uploads’.

    Link to the stackoverflow question: https://stackoverflow.com/questions/49122080/permissions-on-multi-tenant-hosted-server-on-amazon-linux-for-wordpress

    Anyone got any ideas how to even troubleshoot this?

    • This topic was modified 8 years, 2 months ago by Pendo.
    • This topic was modified 8 years, 2 months ago by Pendo.
    • This topic was modified 8 years, 2 months ago by Pendo.
Viewing 4 replies - 1 through 4 (of 4 total)
  • jayhill

    (@jayhill)

    8 years, 2 months ago

    Add the somesite user to the www group and that should work in theory.

    Thread Starter Pendo

    (@msuemnig)

    8 years, 2 months ago

    Then somesite will have access to change all the other sites, which is what I’m trying to avoid. Or, am I incorrect?

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    8 years, 2 months ago

    I have numerous web sites hosted on an AWS Amazon Linux Lightsail VM.

    Cool.

    A couple of my customers would like access to directly make changes to their files.

    That could get very sticky very quickly.

    Here is where the really crazy stuff starts. Using that new username+key file, I can upload media via WordPress

    Expected.

    but I can’t install any plugins via the WordPress admin. WordPress prompts me to enter the FTP information, typical if you have the permissions screwed up.

    I think here is the problem. WordPress (the webserver really) is running as one user ID different from the new username+key. So regular file level access will work for username+key but the webserver’s user ID won’t work.

    If you make the ownership too permissive then you could get into even deeper trouble.

    Is there any chance you could have the customer copy their files to a provisioning directory in their own home directory then run a script to make a copy of those files to the WordPress directory?

    The process running the script should be the same ID as the webserver and the webserver’s directories should get the old correct ownership and permission. That way you just need to expose the customer provisioning directory to the webserver at the file/directory level.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    8 years, 2 months ago

    I’m unfamiliar with Amazon services in particular, but I’m familiar with shared hosting using Apache setups. Presumably each user has their own home folder, and the public_html for each user is in there, and they can access that. Thus, each user has their own WordPress installation, single site, more or less.

    For security, here’s how I’d do it.

    First, you don’t want the WordPress files to be owned by Apache/www. This is actually antithetical to security for a multi-user system. See, if WordPress is owned by the shared apache user account, then that means it has access, potentially write access, to all the WordPress files on all accounts. So I could write a PHP script, have WordPress run it on my site, and modify all the other sites on the same server.

    What you need is to change the way you run PHP from Apache. This is commonplace on shared hosting configurations, and it’s called “setuser” or “suexec” or “su-php” or various different variations involving “su”.

    How to do it depends on your existing setup, but what it does is to change the way Apache loads the PHP process.

    Normally Apache runs as “apache/www” and so when it launches the PHP process, PHP runs as “apache/www” as well. What you want it to do is to actually run the PHP process as “username” instead. That way, the PHP process only has access to that user’s files, and not any other user on the system.

    But you have multiple users. So, how does it know which user to run as? Simple: It uses a PHP which checks the file it is running to start with, and sets its own permissions, its own process owner, to whoever owns that file. Thus, the WordPress files are owned by “username” and then suPHP runs and sets it to be owned by “username” as well, and continues as that user for the rest of the process life.

    Alternatively, Apache has a special build called “suEXEC” which launches the normal PHP process as the other user in question. It has some different config settings needed, and most default Apache builds don’t have it, so you may need to build your own.

    So when I look at a site on aaa.com, then it runs as the aaa user. When I look at a site on bbb.com, it runs as the bbb user. And the bbb user can’t access aaa’s files.

    Also, in such a configuration, no FTP prompt happens. It’s owned by aaa, it’s running as aaa, so it can do what it likes with the files and directories and such.

    You will need to examine your Apache configuration to determine how PHP is running. Whether it be mod_php or FastCGI or other, there is an alternate configuration and probably package to let you run suPHP instead. This is the real answer to your problems for shared hosting while maintaining cross-user security.

    Amazon doesn’t support it, most likely. You’ll have to figure it out yourself to get it to run on their systems. But it can work, if you’re capable of building your own Apache from source, or using external packages not offered by Amazon by default. All modern shared hosting systems use some form of this method. If you get a shared host from any of the majors, you’re using this.

    More commonly, and Amazon might have documentation on this, look into use of “php-fpm”: https://wiki.apache.org/httpd/PHP-FPM which does the same thing, in a different way.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Crazy Permissions’ is closed to new replies.