1

I have been tasked to set up a new server for our web project hosting. I'm a developer, so my systems administration level is quite low.

I have come up with a somewhat simple solution that each project will have it's own UNIX user and that the webroot will be under user's $HOME.

The structure is as simple as:

  • /home/<user>/web
    • /home/<user>/web/log — log files.
    • /home/<user>/web/www — web document root.
    • /home/<user>/web/www/public — just a practice that has come up with various web application frameworks to separate document root from public root.

Now, I want to set permissions in such a way that:

  • /home/<user>/web — can neither be deleted, nor new files/directories added. chown root:root helps here.
    • /home/<user>/web/log — is read only to the user, which I can also manage by a simple chown root:root.
    • /home/<user>/web/www — this shouldn't be possible to delete/edit, but contents freely modifiable (except public). Create, delete, edit both files and directories.
    • /home/<user>/web/www/public — shouldn't be possible to delete/edit, but contents freely modifiable.

For other security and isolation related features, I have opted to use .

So far I have tried chattr +a - it allowed me to add new contents, edit contents, but I couldn't delete them.

While writing the question, similar question section showed Prevent a subdirectory from getting deleted / enforce a directory structure, which works and I am looking to use it for now.

But are there any other, more transparent ways of setting these directories up as such?

  • Also backups, as users will undoubtably find other ways to mess things up besides deleting the directory itself – thrig Oct 27 '17 at 0:12
  • @thrig yeah, those are already in place. – joltmode Oct 27 '17 at 6:20
1

Deleting a directory requires write permission on its parent. The permissions and ownership of the directory are irrelevant. So if you want to prevent deleting /home/theuser/web, it is necessary and sufficient¹ to ensure that the user does not have write permission on /home/theuser.

Do note that when you write “a chown root:root helps here”, that's on the parent directory to prevent its deletion, and on the directory itself to prevent adding or removing files (but not modifying existing files).

Note also that to make /home/theuser/web/log read-only in a useful way, it is not enough to ensure that the user does not have write permission (and does not own the directory). If the user was allowed to write to /home/theuser/web (or /home/theuser or /home or /) then they could rename /home/theuser/web/log (or /home/theuser/web, etc.) and create a new directory log which they would own.

For /home/theuser/web/www and /home/theuser/web/www/public, you can make www and www/public owned by root, but give the user write permissions, and set the sticky bit on www. When a directory has the sticky bit, there is an additional requirement to remove files inside it (including immediate subdirectories — directories are a type of file): a user may only remove files that they own. This way, public will only be removable by its owner (root), but anything else can be freely manipulated by the user.

chown root:root web/www web/www/public
chmod u=rwx,go= web/www web/www/public
chmod +t web/www
setfacl -m u:theuser:rwx web/www web/www/public

Note that it could be any non-theuser ownership, it doesn't have to be root.

¹ Under reasonable assumptions, i.e. all necessary traversal rights, no relevant SELinux rule, etc.

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.