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 webserver 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 the 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.