LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 06-12-2017, 04:03 PM   #1
Adrian5
LQ Newbie
 
Registered: Dec 2014
Distribution: Xubuntu 18.04
Posts: 10

Rep: Reputation: Disabled
Ownership/permissions in a webserver context


I'm having difficulty setting up ownership/permissions for a website CMS.

I have three users that I care about: PHP (FPM-pool), Nginx, and me (sftp/webadmin, if you will).

The CMS (and thus PHP) needs to have full permissions, since it needs to create and delete files, rewrite its own structure during updates, etc. This is a notoriously frustrating exercise if permissions aren't set loosely.

Nginx only needs read permissions (execute on folders).

I as the admin/maintainer would like to be able to comfortably modify anything without invoking superuser privileges.

Now the CMS documentation suggests to set 775/664 permissions for this purpose, but this is not the OS (Ubuntu) default, requiring considerable manual intervention (I may not want everything in that directory tree to have those permissions). From what I understand, I can ensure that ownership propagates as the directory/file tree evolves, by setting sticky bits. But ensuring that permissions stick is impossible, unless I run the PHP master process with a different Umask, which I may not desire when running additional websites/pools under it.

If it was possible to have more than one owner (not owning group), I would make Admin+PHP owners and run with the default 755/644 permissions – free of headaches.

Could you lay out some sane approach to me, where I can edit my files and leave the CMS to evolve without recurring manual intervention? Thanks.

Last edited by Adrian5; 06-12-2017 at 04:06 PM.
 
Old 06-12-2017, 05:48 PM   #2
Laserbeak
Member
 
Registered: Jan 2017
Location: Manhattan, NYC NY
Distribution: Mac OS X, iOS, Solaris
Posts: 508

Rep: Reputation: 142Reputation: 142
I'm not exactly sure what you're doing, but when maintaining a website, particularly one open to the entire Internet, not some Intranet site, you want to make everything as secure as possible, with the least permissive permissions possible.
 
Old 06-12-2017, 06:04 PM   #3
AwesomeMachine
LQ Guru
 
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,513

Rep: Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004
You can create a group, make that group owner of whatever you want, and make php and admin members of that group.
 
Old 06-12-2017, 06:19 PM   #4
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_12{.0|.1}
Posts: 5,171
Blog Entries: 11

Rep: Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092Reputation: 3092
You do not say what your CMS is, but I think we can guess it is PHP based and resides below the httpd root (i.e., in the website directory tree).

EVERYTHING in that tree needs to have the most restrictive permissions possible.

So, all files in that path need to be owned by a restricted, non-privileged user (if not the httpd user) and belong to the httpd user group.

You probably want to run PHP-Fpm pools as the httpd user/group so that they will not have any different permissions on those files. You would set that with user and group rules in the pool config file.

Quote:
Originally Posted by Adrian5 View Post
I as the admin/maintainer would like to be able to comfortably modify anything without invoking superuser privileges.
No you don't...

If your admin user is the owner of the webtree (myuser in the example below), then that is not a problem. But if you mean that user should be able to modify things outside the webtree... don't go there!

I am not very familiar with nginx, but I think the same basic things apply for any *nix hosted webserver.

Here is a contrived example, assuming nginx is the httpd user/group and myuser is the owner of the web tree:

Code:
php-fpm-pool.conf
; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = nginx
group = nginx

ls -l /path/to/webtree/...
-rw-r--r-- 1 myuser nginx 114 May 17 15:56 files.php
  OR in some special cases
-rw-rw-r-- 1 myuser nginx 114 May 17 15:56 files.php
When you are logged in as myuser you want to be able to only do damage in your own, very limited scope!

When you need to do other things, you need to assume the appropriate powers to do them.

The basic thought to absorb is this: When (not if) some web attacker finds an open door and becomes "myuser" through the web interface, how much damage could they do?

Last edited by astrogeek; 06-12-2017 at 06:52 PM. Reason: Added comment
 
Old 06-12-2017, 06:45 PM   #5
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,629

Rep: Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204
html files should be owned by the maintaining user and have permissions of 644
Executable scripts should be owned by the maintaining user and have permissions of 755 (to be executable -- duh)
Files that the scripts need to add/delete/maintain should be owned by the webserver user and have permissions of 644 - although they may be in a directory that is owned by the webserver user that is 755
That user is defined in your httpd.conf (for apache)(on my very old configuration, that user is nobody -- I'm not sure what the current default apache user is.)
Code:
User nobody
Group nobody
It is setting the "data" files to be owned by the webserver user that allows the php scripts to maintain them. Note that they are still "read only" to everyone but that user. That does present some challenges if you want or need to maintain them manually, but if all maintenance is done by the php scripts, you should have no problems.

But I'm going to disagree with astrogeek about the group designation for html and script files in the web server/site directory tree. They do not need to be in the webserver user group, although it won't hurt if they are. They can be in a default group for users unrelated to their being in the web tree. It's only important that they be world readable so that the webserver user can read/execute them. What he suggests would allow them to be 640, which is tighter, but world-readability on web pages is ok, since they're being displayed to the world anyway...
IMO

Last edited by scasey; 06-12-2017 at 07:01 PM.
 
Old 06-13-2017, 04:45 PM   #6
Adrian5
LQ Newbie
 
Registered: Dec 2014
Distribution: Xubuntu 18.04
Posts: 10

Original Poster
Rep: Reputation: Disabled
Hello, thanks for your replies.

Quote:
Originally Posted by AwesomeMachine
You can create a group, make that group owner of whatever you want, and make php and admin members of that group.
I'm aware, but as mentioned in my post, that creates the issue of maintaining 775/664 permissions on a dynamically changing site.

Quote:
Originally Posted by astrogeek
I think we can guess it is PHP based and resides below the httpd root (i.e., in the website directory tree).
Yes, it's all in /srv/www/mysite/.

Quote:
Originally Posted by astrogeek
EVERYTHING in that tree needs to have the most restrictive permissions possible.

So, all files in that path need to be owned by a restricted, non-privileged user (if not the httpd user) and belong to the httpd user group.
I currently have my PHP user (specific to that site) as the owner for all files, and my admin as the group, respectively.

Quote:
Originally Posted by astrogeek
Quote:
Originally Posted by Adrian5
I as the admin/maintainer would like to be able to comfortably modify anything without invoking superuser privileges.
No you don't...

If your admin user is the owner of the webtree (myuser in the example below), then that is not a problem. But if you mean that user should be able to modify things outside the webtree... don't go there!
Are you saying that the admin user (with whom I do my system tasks, like installing applications) should not be involved in touching website content? I don't mean running any scripts as that user, just manually modifying (static) files. If yes, then could you suggest a good arrangement of users/ownership? Should I have a dedicated "webadmin" user for these tasks, with its own separate SSH/SFTP access?

Quote:
Originally Posted by scasey
Files that the scripts need to add/delete/maintain should be owned by the webserver user and have permissions of 644 - although they may be in a directory that is owned by the webserver user that is 755
Wouldn't it make more sense to have the user of the PHP-FPM pool own the files/dirs? After all, it's doing the executing/writing, like an owner would. The webserver should be fine being group (for 750/640) or even other (for 755/644), as reading is all it ever does with website content.

p.s. Could someone elaborate on the persistence of permissions I mentioned in my first post? If I'm not mistaken, PHP creates new dirs/files with 755/644 permissions, unless the master process is run with a different umask (this can be set, e.g. in the systemd service). Is there an alternative way of maintaining 664/775 with dynamically created content?

Thanks.

Last edited by Adrian5; 06-13-2017 at 04:48 PM.
 
Old 06-13-2017, 06:58 PM   #7
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,629

Rep: Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204
Quote:
Originally Posted by Adrian5 View Post
Hello, thanks for your replies.
Quote:
Quote:
Originally Posted by scasey
Files that the scripts need to add/delete/maintain should be owned by the webserver user and have permissions of 644 - although they may be in a directory that is owned by the webserver user that is 755
Wouldn't it make more sense to have the user of the PHP-FPM pool own the files/dirs? After all, it's doing the executing/writing, like an owner would. The webserver should be fine being group (for 750/640) or even other (for 755/644), as reading is all it ever does with website content.

p.s. Could someone elaborate on the persistence of permissions I mentioned in my first post? If I'm not mistaken, PHP creates new dirs/files with 755/644 permissions, unless the master process is run with a different umask (this can be set, e.g. in the systemd service). Is there an alternative way of maintaining 664/775 with dynamically created content?

Thanks.
What I said in my earlier post is based on my experience developing and hosting web-based applications. The cgi scripts are not run by the owner of the scripts...they are run by the webserver user, and the files they create are not owned by the owner of the scripts. Files created by applications run on an httpd service/server will be and are owned by the webserver user.

To summarize, you only need one "real(human)" user: "me" in your original post, although that should not be your "administrator" user account, but, as has been stated, a "normal" limited-access user used exclusively to maintain the website(s). I even make my customers who maintain their own sites have separate IDs for mail and web/ftp (or sftp), even if there's only one mailbox for the domain.

As to the permissions...first, it should be 644 and 755. There's no need to have group writeability, even if you do as astrogeek suggested re: the group of the "human" maintaining user. Since you only need to deal with two users, set the "human" user's umask as needed (002?--I get confused about umasks). The webserver users permissions should already be set that way, but check to see.

Have you actually tried to run a script yet? One that creates a file? (something in php that creates and outputs to a non-existing file, for example). If I'm right (and I'm only telling how things are working for me) you'll get an error because the script can't create a file in a folder the webserver user doesn't own. It can write to a directory owned by the webserver user with 755 permies.
[Ahh. so if the folder it wanted to write to was 775, it would be able to write to it...so thats astrogeeks point!!]. My point is that then so could any "real" user set up that way, as you could, theoretically, have several "real" users for maintenance, if there are multiple sites/domains hosted on the server. [Which is the case for my setup]

If configured as I'm recommending, the "human" user of site/domainA can't mess with (or even see, if things are configured correctly), the files of site/domainB. The webservers virtual domain function would prevent domainA's scripts from impacting domainB's files, even though both sets of files are owned by the webserver user as 644 files in 755 directories.
 
1 members found this post helpful.
Old 06-13-2017, 07:38 PM   #8
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
This is actually a very good application for ACLs = Access Control Lists, which allow you to "step outside of" the usual "Unix-style permissions mask" and to define more specific controls for files and for directories.
 
1 members found this post helpful.
Old 06-14-2017, 11:09 AM   #9
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,629

Rep: Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204Reputation: 1204
To demonstrate the concepts I'm trying to explain...perhaps not clearly...try this:
1. as an unprivileged user (me), create a simple script that creates a file in that user's $HOME (/home/me for example) named tester.sh.
Something like:
Code:
#!/bin/bash
echo This is a test > lqtest.txt
tester.sh will (should) have 644 permissions.
2. chmod 755 tester.sh to make it executable
3. execute it:
Code:
./tester.sh
then 
ls -l lqtest.txt
-rw-r--r--  1 me me 37 Jun 14 06:37 lqtest.txt
It is owned by me and have the permissions 644. Agreed?
then
Code:
rm lqtest.txt
4. now su to root
repeat step 3.
Code:
./tester.sh
then 
ls -l lqtest.txt
-rw-r--r--  1 root root 37 Jun 14 06:37 lqtest.txt
Note that lqtest.txt is now owned by root

Absent any coding to manage ownership in the script being called (e.g. php scripts in your CMS), the files it creates will have the ownership and permissions of the user that runs it (the webserver user), not the user that owns the script.
 
1 members found this post helpful.
Old 06-17-2017, 05:47 AM   #10
Adrian5
LQ Newbie
 
Registered: Dec 2014
Distribution: Xubuntu 18.04
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by scasey
To summarize, you only need one "real(human)" user: "me" in your original post, although that should not be your "administrator" user account, but, as has been stated, a "normal" limited-access user used exclusively to maintain the website(s). I even make my customers who maintain their own sites have separate IDs for mail and web/ftp (or sftp), even if there's only one mailbox for the domain.
Ok, understood.

Quote:
Originally Posted by scasey
Have you actually tried to run a script yet? One that creates a file? (something in php that creates and outputs to a non-existing file, for example). If I'm right (and I'm only telling how things are working for me) you'll get an error because the script can't create a file in a folder the webserver user doesn't own. It can write to a directory owned by the webserver user with 755 permies.
Yes, I have experimented with this, creating a file via PHP and looking at the resulting ownership and permissions. The user I've set in my PHP pool becomes the owner, not www-data, which my webserver runs as. Permissions are 755/644 by default and dependent on how the PHP-FPM service (the master process) is launched. When set to use a umask of e.g. 0007, files created by PHP inherit 660 permissions as one would expect.

Quote:
Originally Posted by scasey
To demonstrate the concepts I'm trying to explain...perhaps not clearly...try this:

(…)

Absent any coding to manage ownership in the script being called (e.g. php scripts in your CMS), the files it creates will have the ownership and permissions of the user that runs it (the webserver user), not the user that owns the script.
Thanks a lot for taking the time to explain this to me. You're right of course; I think my setup/environment is just different than yours.
Code:
ll /srv/www/testpage.net
drwxrwxr-x 2 adrian adrian 4.0K Jun 17 12:23 subfolder/

ll subfolder/
-rw-r--r-- 1 adrian adrian 767 Jun 17 11:20 file_test.php
I can open my webbrowser, request file_test.php through my webserver (running as www-data) and the script will execute, creating a new file owned by adrian:adrian. So the user that determines ownership is the one PHP workers run as¹, not the webserver².

¹: so long it can read+write
²: so long it can read

Quote:
Originally Posted by sundialsvcs View Post
This is actually a very good application for ACLs = Access Control Lists, which allow you to "step outside of" the usual "Unix-style permissions mask" and to define more specific controls for files and for directories.
Yes, I think that might be a good option!

Thanks again for the suggestions, I think I'm a step further now.
 
  


Reply

Tags
nginx, ownership, permissions, php, website


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Version controll /etc and permissions/ownership DodoFXP Linux - Software 2 08-01-2010 01:02 PM
I messed up permissions and ownership digity Linux - Newbie 8 12-07-2008 06:02 PM
permissions and ownership on dir gabsik Linux - Software 4 02-05-2007 06:48 AM
Question about ownership/permissions infornography Linux - Newbie 7 07-28-2004 05:57 AM
write permissions / ownership bynaar Slackware 15 08-08-2002 04:25 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 05:01 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration