1

I stumbled upon something odd (for me at least) when using CloudLinux for the first time. I'm a long time Ubuntu user, I would still consider myself novice, though.

I've installed Nginx with PHP-FPM on Ubuntu servers a multitude of times. My usual approach is to setup a user and create a www directory in the user's home directory. I'd setup the PHP-FPM pool configuration user and group to the newly created user and point a Nginx VirtualHost to the users home directory with the document root pointing to that www folder somewhere.

This has worked fine for me on Ubuntu for a long, long time.

Last week, tried setting up the same on CloudLinux (which to my understanding is a CentOS distrobution of some sort).

The result was quite different. I had no issues having Nginx execute PHP files, but I found that Nginx couldn't serve static (or other files, not handled by PHP-FPM). Fast forward some debugging, it became apparent that the nginx user didn't have sufficient permission to read the /home/user/www folder. The quick fix for me was to move the www to /var/www/sitename, update the document root in Nginx and I could be on my way.

This just made me think about what the actual difference was. Is my approach on Ubuntu even sane (ie. secure) when this didn't work on another distro?

Why can the Nginx user, without problems, read the contents of my user's home directory on Ubuntu, but not on CloudLinux?

Repox
  • 265
  • 1
  • 3
  • 14
  • 2
    Probably something to do with the way they have set up their distro. CloudLinux is a customized distro for *mass* web hosting. The community here has decided not to support mass web hosting software, in large part because they often do very strange things that are only applicable to those systems. – Michael Hampton Sep 14 '20 at 19:09
  • 1
    There's no magic here - nginx has to be able to read the static files to serve them. Wild guess: `/home/user` permissions don't allow other users, namely nginx, to descend into it. That could be a per-distro config that could also depend on how you created the user(s) in both places. – erik258 Sep 14 '20 at 21:52
  • @MichaelHampton That makes sense. It seems like documentation (and support) for CloudLinux, even via the community, seemed lacking in general, but that makes sense if it's a customized distro that acts differently. Thank you for your comment. – Repox Sep 15 '20 at 05:31
  • @DanielFarrell Nobody is talking about magic (or even hinting it). Your 'wild guess' is already covered by the OP. My question is _why_ the difference exists, not what the difference is. – Repox Sep 15 '20 at 05:33
  • Could you please clarify: Are you using a cage and what kind of control panel? Also, what were the rights to the folder and uname -r – Sergey Khristich Sep 15 '20 at 15:29
  • @SergeyKhristich No cage, no control panel, rights to the folder was `drwxrwxr-x` and uname -r outputs `4.18.0-193.14.2.el8_2.x86_64` – Repox Sep 18 '20 at 09:42

1 Answers1

0

If you want ~user/www to be readable by some process, make sure that ~user/www has x-permissions (for all directories from root to the target directory). That x just allows to enter the directory, not to read the directory.

So to read the target directory, also add r permission (w-permission to allow file creation/removal). If the groups of ~user/www and process cannot be matched easily, you may wish to use ACLs (Access Control Lists). See getfacl and setfacl commands for details.

Note this was for the containing directory; do not forget to set permissions for the actual files, too.

U. Windl
  • 366
  • 3
  • 17