file permissions

ahh, were to begin. the basic idea:

through libnss-mysql, www-data is in every customer group (ie the groups for the users in syscp). this way, files can be owned by blue:blue (for user blue) and rwxr-x--- and apache can still read them. the user blue can read/edit the file and other users cannot.
ok, so that works for static files. and it works for php too:

with safe_mode + open_basedir options in php, we can lock down apache so that it will only run php from some certain directories and only allow the reading of files which are the same user as the initial php script.
but what about single install cms code?:

that is a problem. since the single code base will be owned by www-data, then it will only be allowed to include or edit files which are also owned by www-data. this makes it impossible for people to edit their configuration files.
will safe_mode_gid help?:

with safe_mode_gid, then safe_mode will allow a script to read other files if and only if the user's match exactly or the group's match exactly. for example, take user+group x and y:
    script    file   result
    ------    ----   -------
    x:x       x:y    ok - users match
    x:x       y:x    ok - groups match
    x:y       y:x    failure
(however, i have seen this work in other mysterious ways when one user is a member of another group. however, i haven't been able to reproduce this on different machines or with different users.)
safe_mode_gid helps sometimes:

safe_mode_gid allows an uploaded file to be blue:www-data. This is ok for files which don't contain sensitive information. For configuration files with passwords, this is no good: user cannot set the group to be www-data unless they are in the group www-data. If they are in the group, then all the other users are too, and then the other users can read the configuration file. Because of this, php files which must be included from the single code base but which reside in the user's directory and contain sensitive data (such as config files) must be owned by www-data, with group set to the user's group.
in conclusion:

  • the user www-data is in all other groups.
  • if a static file is to be read by apache, it can be blue:blue.
  • if the user uploads their own php files, the permissions can be blue:blue for all their code, files and directories.
  • when running code from the central codebase, the ownership of the central code is www-data:www-data. This means that any file it is going to read MUST have either group or owner be www-data. since the user does not have the ability to chown the group or owner to be www-data, we must set the permissions for them on all php configuration files.
  • this is a big pain in the ass with files created by www-data: a cms might create lots of files all the time. in order to allow these files to be editable by the user, we use setguid: this makes it so that files created by www-data will automatically get assigned to the user's group. by default, the software dispenser creates directories owned by www-data, group of the user, with setguid, and no world permissions. The permissions look like this:
    drwxrws---  8 www-data blue
summary table (for user 'blue'):

perms         ownership        usage
----------------------------------------------
drwxr-x---    blue:blue        (1)
drwxr-x---    blue:www-data    (2)
dr-xrwx---    www-data:blue    (3)
drwxrws---    www-data:blue    (4)

usage notes:

(1) most files, including html and images. This even includes php, if it does not need to be opened by a central code base.
(2) php files uploaded by the user but which must be read by a central code base. The user will have to chown www-data on these files.
(3) sensitive configuration files which must be read by a central code base, but which other users must not be able to read. A user will not be able to set the owner to be www-data: we must create these files for them.
(4) files created by www-data in setguid directories. for example, uploaded images, etc.
These are the minimum permissions: you can always grant wider access if you want. However, the group and user ownership must exactly match what is listed above for (2) and (3).

custom code

If someone has custom php code, it can be owned by blue:blue with no problems. Alas, if the web application allows people to upload files, then we have a problem because those files will be owned www-data:www-data. To get around this, we can use setgid and safe_mode_gid to make it so that the files have a group of blue, so that the php scripts can read/modify/delete them.

for example, setting directory permissions on an 'images' directory:

# chown www-data:blue images
# chmod u+rwx images
# chmod g+rwxs images
# ls -ld images
   drwxrws---    5 www-data blue  488 Dec 11 01:08 images

vhost configuration:
php_admin_flag safe_mode_gid 1