Project Web Filesystem Permissions

Project Web Filesystem Permissions

Our new project web has a special filesystem that has permission features different from the standard user+group+other permissions:

Overview

Permissions bits are in a standard trio of "rwx" (read/write/execute) sets, but the normal "user" (owner), "group", and "other" categories are replaced by the trio of "project member", "project-initiated apache access", and "everyone".

Executive Summary

For those that don't want to read all the details, remember these simple rules for installing software onto the new project web:

  • Make sure that any files that contain secrets (such as DB passwords) are not marked as being world-readable.
    • Do not try to rely on the containing directory to make a file unreadable.
  • If you need the web server to be able to write a file and/or directory, change the mode to be group-writable.
    • However, don't set too many things as group-writable, or you'll set yourself up for unexpected changes by hackers.
  • Project members will always be able to manipulate their project's files (chown, delete, change, etc.) no matter who created the file (though you may need to chmod a file/directory to a writable state to be able to change it).

The Details

Here are the 3 categories of permissions broken down in detail:

Project-Member Permission (in "user" bits)

  • Any user who is a member of a project with shell permissions gets these rwx permission bits for the project's files.
  • A project member can always chmod any project file (unless it is owned by root).
  • The project-member read bit is always enabled, and may not be turned off (i.e. u=r or 0400).
  • When a file is created, it will be marked with the user that created the file, but that association does not signify any extra permissions (with one exception -- see below).
    • This means that if a user is no longer a project member, the project-member permissions don't apply, even to files they created.
    • The only exception to this rule is for a file owned by the apache user:
      • The apache user can chmod project-related files that are owned by apache (for files related to the initiating request).
      • The apache user does not ever benefit from project-member permissions, even on the files that are owned by the apache user.

Project-Initiated Apache Permission (in "group" bits)

  • All files are marked with a group of "apache", and this may not be changed.
  • This special apache access only applies for a project's access to its own files from the web servers.
    • For example, a web request related to "project1" does not get apache access for a file in "project2".
  • If user "apache" is creating a file, the "group" permissions will be set to match the "user" permissions.
    • This ensures that a file that the apache user creates will have the expected access permissions when the apache user tries to access the file.
    • If some software manually overrides permissions after file creation, make sure to configure it to include the "group" apache bits.

Everyone Permission (in "other" bits)

  • These permission bits are always checked first for all file accesses.
    • If they do not authorize the requested access, then the requesting user will be categorized into one of the 2 prior permission checks for the final access determination.
  • The write bit for "everyone" is always off, and may not be turned on (i.e. o=w or 002).
  • When a new file is created, the read permission for "everyone" will default to disabled if its parent directory is not everyone-readable.
    • Some software may override the default permissions after (re-)creating a file, so if a web request may edit a file with secret info in it, verify that the permissions do not become everyone-readable after the software writes the file.

General Comments

  • All directories are always "usable" (able to be referenced in a path) by everyone, and this cannot be changed (i.e. a=x or 0111).
    • This means that every secret file needs to be marked as unreadable in the "everyone" permissions.
    • It can help to put secret files in a directory that does not have the "everyone" read-bit set, so that any recreating of the file will default to being unreadable by "everyone" (though you should also check to ensure that your software doesn't override the default).
  • There is no need for a mode 1777 directory (tmp-dir setup) because apache requests (for the current project only) can write to a mode 0775 (or 0771) dir.
  • Any attempt to chown/chgrp a file (except by root) is ignored (silently, which avoids annoying copying errors).
  • If you chmod a file or directory to try to turn on/off a forced permission bit, it will be silently kept unchanged.
    • Minimum file perms: 0400, minimum dir perms: 0511, maximum file/dir perms: 0775.
    • No "super bits" are ever set.

Optimizations

For fastest access, make as many files & directories world-readable as possible. If you only disable world-reading for files containing secrets (and possibly their containing directories), the filesystem won't need to figure out project membership or httpd-request association for the majority of the read requests. This results in a very slight speed increase.


Related

Documentation: Project Web Services