[SOLVED] NGinX, document root, permissions & ownership

[kgdrenefort]

Hello,

Goals :

My goal is to have a separated UNIX user (let's say srvadm) to manages data on the DocumentRoot of the future NGinX's virtual host I have to migrate on it. I want to properly manage how nginx user/group would interact with the DR's data (to serve files) aside this users who would add/remove/modify/rename files and directories. As creating new virtual host directories and files hierarchy, without being allowed anything else on the system, beside being able to read logs of VH.

This is how I imagine I should handle this:

1/ Separate from the classic path (/var/www) the DocumentRoot, on another disk, no needs to bind anything to simulate the classic path.

2/ Add a UNIX user, without any permissions on the system, besides:
a) Read, write and execute regarding what it try to do (no need to get execution permission for an index.html… but for directories yes if I want it to go inside !), inside the DocumentRoot only.
b) Not being able to login from a password on the command line or any kind of session (not even TTY), specially not from SSH/sFTP or any remote way (LAN or WAN). Only from the su - command locally, from root user or my every-day user if it's not goofy.
c) Won't be able to do anything beside a) and b), even logs would be moved elsewhere from /var/log and this user would need as well to be able to read them, being able to execute directories (access inside), but no need for write or execute for files.

3/ "other" would have not a single right into the DocumentRoot and logs directories, only root (duh) and this user would be able to access these, not even my every-day user.

My problem:

I do not know what would be the best:

Case I/ :

Set this user as the main owner of the DocumentRoot (srvadm:nginx), allowing it to rwx directories and rw files, allowing aside nginx group permissions to serves external request.

Case II/ :
Set this as group instead of main users (nginx:srvadmin), allowing it the same than I/, but keeping nginx as the main user, and only srvadmin as group.

It might sounds a bit of an overthinking, but I really wonder what would be the best, easiest and most secure way to handle this. I question myself too because I am currently thinking of the defaults user:group as user, group and other permissions. For other, would always be no-rwx (0), don't need it, unsecure too.

To be honest, I am currently writing my own BASH script to create this directory hierarchy inside the root of NGinX with the propers ownership & permissions, because I do not add a site very often and it's easy to forgot what was the good way, how you did it, without taking dirty shortcut.

If solution I/, it would means:
Files handled by user (srvadmn) would need u:rw- (6), to create/remove/modify files as reading them. It does not need to execute anything in this context.
Directories handled by user (srvadmn) would need u:rwx (7), to create/remove/rename these dir, but also get into the directories (so x is needed).

Files handled by group (nginx) would need g:r-- (4), to serves the files as requested on internet, no need to write or execute either.
Directories handled by group (nginx) would need g:rx- (5), to serves files inside them as requested on internet, no need for writing too.

It would mean, in this case, these kind of permissions and ownership:

- srvadm:nginx, files: 6 (rw-) 4 (r--) 0 (---), so 640 (- rw- r-- ---) for files.
- srvadm:nginx, directories: 7 (rwx) 5 (r-x) 0 (---), so 750 (d rwx r-x ---) for directories.

If solution II/, it would means:
Files handled by user (nginx) would need u:r-- (4), to serves files only, without being able to create/remove/rename anything. Or execute, not needed.
Directories handled by user (nginx) would need u:r-x (5), to serves files into these directories by going into them, no need to create/remove/rename anything.

Files handled by group (srvadmn) would need g:rw- (5), to create/remove/modify/rename any files as needed, without being able to execute anything.
Directories handled by group (srvadmn) would need g:rwx (7), to create/remove/modify/rename any directories needed, as going into these directory since it would be needed.

It would mean, in this case, these kind of permissions and ownership:
- nginx:srvadm, files 4 (r--) 6 (rw-) 0 (---), so 460 (- r-- rw- ---) for files.
- nginx:srvadm, directories 5 (r-x) 7 (rwx) 0 (---), so 570 (d r-x rwx ---) for directories.

Résumé:

Case I/:
- User & group: srvadm:nginx
- Files: 640 (- rw- r-- ---)
- Directories: 750 (d rwx r-x ---)

Here the user (srvadm) could read and write on file, but no execution (not needed). It'll be able to have full permissions on directories.

The group (nginx) could only read files, no write and execution. The group could read and execute (going into) directories to be able to reach files to serve.

Other won't be able to do anything, files or group.

Case II/:
- User & group: nginx:srvadm
- Files: 460 (- r-- rw- ---)
- Directories: 570 (d r-x rwx ---)

Here the user (nginx) could only read file, no writing or execution. It'll be able to read and execute (going into) directories to be able to reach files to serve.

The group (srvadm) can read and execute (going into) the directories to work with files. It'll will be able to read, write and execute directories (going into) to works with file. (opening, creating, modifying, renaming and removing them).

Other won't be able to do anything, files or group.

PS: I do know how theses works mostly, but it really start to be confusing easily between number code and alphabetical sign (rwx), as mixing who needs what and not more, etc. I tried to review my post several times to catch up typo or error, sorry if there is still some.

Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.

[bitwisegamgee]

Greetings,

So here are my thoughts:

1. You create a user and set permissions:

[Hu]

The owner of a file can change the file's mode, so if nginx owns the files, the case 2 mode of r-- will only present a minor hurdle to something that seeks to change the files. Rogue code running as nginx could chmod +w the files, then write to them anyway. The case 1 approach where nginx is only a group member is safer in this regard. Only the srvadmin user can change the mode, and the active mode prevents nginx from writing to the file without a mode change.

If you want to be cautious, you could run nginx in a mount namespace where the whole hierarchy has been remounted read-only. That will prevent writes even if the permissions are too lax.

[kgdrenefort]

Thanks for the answer.

From your answer, Hu, I'm glad to have asked => I completely forgot this behaviour, which leads me to, for now, consider the first choice, at least only the user in charge of the file would be able to touch them, while nginx will simply read them.

The mount only things could be nice, but maybe later.

Thanks for your answer too bitwisegamgee.

I leave this topic open a bit, maybe someone would point out another great stuff to know.

I'll keep going on my test.

Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.

[kgdrenefort]

Just realising chown can't be used from srvadm to change the owner if not root. Fat luck :).

I could add sudo and allow this user to run the chown command I need, but maybe you know a better and practical way instead of installing sudo (which I was not needing until now).

This user isn't allowed to get more privileges with su, blocked.

I would love to avoid to run doas, sudo, if it's possible, to keep things simple as it could be. But if there is no other ways, I'll deal with it.

And of course I would like to avoid needing any more permissions (like using root), but at some point, I have to get the good permissions to execute this, simple as that :).

Open for suggestion.

Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.

[Hu]

Why do you bring up chown? Prior to your most recent post, we were looking at having srvadm own the files, srvadm set the group to nginx, and srvadm set the file mode bits. That should all be fine without root. As you say, chown needs root, but I do not understand why you need chown at all.

[kgdrenefort]

[kgdrenefort]

After some reading and testing, I'm still stuck.

I tried chgrp and chown to change from srvadm (the non-privileged user) the groups of my directories to nginx, fat luck still.

I saw my srvadm user needs to be in the nginx groups as well, so:

[Hu]

To use chgrp as an unprivileged user, the target group must be one in which the calling process is a member. You showed groups srvadm, but this looked up the groups that a newly logged in srvadm would normally be issued. Your shell actually using srvadm might have a different group list, particularly if it predates you adding the nginx group to the srvadm user. What is the output of id; chgrp nginx /the/path, all from the srvadm shell that you want to use?

Using chgrp is just a shortcut when you know you will not change the ownership. Calling chown as an unprivileged user can work if you use it only to change group membership, but not the file's owner.

File mode permissions will not lead to EPERM for chgrp, so we can ignore the file mode bits for now.

[kgdrenefort]