Access and Permissions on a Webfusion shared service

The ownership and permission system on the shared Webfusion LAMP services are somewhat odd and merit being documented.  Here is a listing of an appropriate subset of the access and ownership of my directory hierarchy.  I’ve started at /websites/LinuxPackage02/el/li/so. (I’ve substituted “ROOT” here to keep the listing lines from wrapping and also _UID_ for my UID.)

drwx--x--x   3   root   root  2048  Oct  1  2009  ROOT/
dr-x--x---   4  _UID_ apache  2048  Mar 15  2010  ROOT/
drwxr-x---   2   root  _UID_  2048  Nov 21 00:49  ROOT/
drwxrwxr-x  10  _UID_  _UID_  2048  Nov 26 13:15  ROOT/
-rw-r-----   1   root _UID_ 245858  Nov 26 23:58  ROOT/
drwxrwx---   2  _UID_  _UID_  2048  Nov 26 12:50  ROOT/
drwxrwxr-x   9  _UID_  _UID_  2048  Nov 26 13:03  ROOT/
drwxrwxr-x   5  _UID_  _UID_  2048  Mar 10  2010  ROOT/
drwxrwxr-x   6  _UID_  _UID_  2048  Oct  2  2009  ROOT/
drwxrwxr-x   2  _UID_  _UID_  2048  Jun  4  2006  ROOT/
drwxrwxr-x  13  _UID_  _UID_  4096  Oct  5 19:42  ROOT/
-rw-rw----   1  _UID_  _UID_  1464  Nov 22 22:54  ROOT/
-rw-rw----   1  _UID_  _UID_   282  Oct 17 23:19  ROOT/
-rw-rw-r--   1  _UID_  _UID_   166  Aug 27 06:42  ROOT/
drwxrwx---   2  _UID_  _UID_  2048  Nov 26 12:05  ROOT/
drwxrwx---   2  _UID_  _UID_  2048  Nov 26 13:29  ROOT/
drwxrwx---   2  _UID_  _UID_  2048  Nov 26 11:50  ROOT/
drwxrwx---   2  _UID_  _UID_  2048  Nov 10 16:26  ROOT/
drwxrwxr-x   3  _UID_  _UID_  2048  Nov  8 13:32  ROOT/
drwxrwxr-x   4  _UID_  _UID_  2048  Sep  9 19:38  ROOT/
drwxrwxr-x   4  _UID_  _UID_  2048  Nov  2 21:00  ROOT/
-rw-rw----   1  _UID_  _UID_ 10416  Nov 22 23:36  ROOT/
lrwxrwxrwx   1  _UID_  _UID_    10  Oct 17 23:40  ROOT/ -> ../php.ini

Each hosted user such as me has read access to his or her account directory but not write access, so can’t create any sub-directories.  Only two sub-directories are set up.

  • The logfiles directory is owned by root but in the user’s group, and the Apache access log records are copied into this directory on a nightly basis, and aggregated into a weekly summary (I’ve included the listing for one above).  Users can access their logfiles through group access, but not modify or delete them.  This is done by the aggregation utility which runs as root.
  • The public_html directory is owned by the user, and the user has full control over this and any subdirectories.  The default umask is 0002.  This is the only directory hierarchy where the user can create content, so “public_html” is really a bit of a misnomer.

Since Apache service runs under the apache UID, and the apache account does not include group membership of all the hosted users groups, each user must grant other=execute access to all directories on a path to any file which Apache needs to access.  Whether they need other=read is moot unless of course you have enabled web directory browsing. The files themselves must have other=read access.  If this access isn’t set then Apache will fail to retrieve the files.

An exception to this is that any php scripts are first processed by suPHP which runs as root and therefore these don’t need any other access.  suPHP spawns the PHP interpreter under the UID of the file, and hence only the user permissions need to be set.  Again, any files accessed by the interpreter in the execution of the PHP script will use the user’s permissions.

So in the case of my public_html directory, the sub-directories b, files, janetscurtains, terry and wf are all mapped subdomains and have other:read+execute access to enable Apache to read them.  _private is a common subdirectory that I use for backup and distribution.  I only access this through PHP scripts and FTP and so this has other:none to prevent Apache access.

Likewise the sub-directories of my blog application that need to be directly served by Apache (themes, images and includes) have appropriate access enabled but the directories only accessed programmatically (_admin, _cache, _include and _templates) have other access disabled.

Note that I don’t bother differentiating between owner and group, since there is a 1-to-1 relationship between these on the Webfusion set-up.

Most importantly, note that index.php (which contains “secret data”) also has other access disabled.  Why is this? I, as a normal user, cannot browse above the /websites/LinuxPackage02/el/li/so/ directory.  However, since the default access to all public_html directories is other:read+execute access, if I happen to know that is hosted on Webfusion then I will be able to browse and read the file hierarchy /websites/LinuxPackage02/so/me/co/ including any data files and PHP files which contain MySQL user/password data etc.  if this user has left his protections at the Webfusion defaults.  A bit of a security hole, eh?

Leave a Reply