0

I'm primarily trying to set permissions inside of /var/www . We are using a project format which has the following structure in common for each project:

  • /var
    • /www
      • /runtime
        • /shared
        • /project.com
          • /application
          • /static
          • /service
          • /support
        • /site.com
          • /application
          • /static
          • /service
          • /support

Currently:

  • Web server (nginx) is the primary owner of all directories
  • /shared directory essentially contains libraries / library code which any application may use.
  • /application is started up by a file in the root of any project directory (e,g site.com)
  • /static has sub directories, usually /img, /css, /js, /feed . These may not execute.
  • /service contains web/system services which run directly (subdomain bypasses root file)
  • /support contains files which are loaded only by the application, but should never be served. (classes, templates, etc)

I'm able to get this working fair enough, but I am fairly sure I'm not doing so properly. Way too many 755s; and I have poor understanding of sticky bits which I'm about to google deeper.

On the development servers the bulk is meant to be owned by nginx:dev, where nginx is also in the dev group. on staging this is nginx:admin, on productions it is nginx:appupdater

My main goal today is that I'd like for the devs group to have the ability to create and edit any of the files within a project directory (project.com, site.com,...) while the /shared directory should only be updated manually very infrequently.

For one thing, I'd want to set permissions such that new files will be owned by nginx:devs and developers can freely upload and alter them on the dev server. I'm trying to get permissions best at denyomg access wherever possible while allowing apps running (as nginx) to load files from support and application directories. The only exception is a need for writing in /static/upload and a folder in /support/generated

How can I secure this permission-wise so that that we can still run apps, allow developers to access and create files without overriding the owner:group, and generally not shoot myself in foot if a user uploads executables?

(aside from app/server checking for me)

That Realtor Programmer Guy
  • 223
  • 2
  • 8

1 Answers1

2

Long time ago I concluded that the best way to share a web project among a group of users is to force them to use sudo or ssh to always login as the single dev user used for all project files. If you need to track changes by individual developers, it's better to let them work in their own environments and the above would then apply to release engineering instead of developers.

With sudo you can grant permissions to access the user to a system group and then add users to the group. With ssh you need to add user SSH keys directly to the dev user's .ssh/authorized_keys.

Before that I tried many techniques employing permissions and posix draft ACLs but they turned out to be useless. Especially setting execute bit on a file is reserved to the owner, that's why I prefer all users to switch to the owner UID before making any modifications.

They also have a notion of the project they are working on and a home directory so it's much easier to maintain the shared resources.

The application can then run under a different user (possibly in the same group) which only has read access to the data except the directories you mentioned. You don't need a sticky bit in a more or less single user environment. It's intended to guard files in tmp directories from non-owners.

A theoretical solution is to use a powerful ACL system like NFSv4 ACLs but native support for that is generally not available. There are patches but you probably don't want to spend your time with that and finally have a more complicated solution than the one I described above.

Pavel Šimerda
  • 183
  • 8