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/ellisons.org.uk drwxr-x--- 2 root _UID_ 2048 Nov 21 00:49 ROOT/ellisons.org.uk/logfiles drwxrwxr-x 10 _UID_ _UID_ 2048 Nov 26 13:15 ROOT/ellisons.org.uk/public_html -rw-r----- 1 root _UID_ 245858 Nov 26 23:58 ROOT/ellisons.org.uk/logfiles/2010-Nov-Week4.log drwxrwx--- 2 _UID_ _UID_ 2048 Nov 26 12:50 ROOT/ellisons.org.uk/public_html/_private drwxrwxr-x 9 _UID_ _UID_ 2048 Nov 26 13:03 ROOT/ellisons.org.uk/public_html/b drwxrwxr-x 5 _UID_ _UID_ 2048 Mar 10 2010 ROOT/ellisons.org.uk/public_html/files drwxrwxr-x 6 _UID_ _UID_ 2048 Oct 2 2009 ROOT/ellisons.org.uk/public_html/janetscurtains drwxrwxr-x 2 _UID_ _UID_ 2048 Jun 4 2006 ROOT/ellisons.org.uk/public_html/terry drwxrwxr-x 13 _UID_ _UID_ 4096 Oct 5 19:42 ROOT/ellisons.org.uk/public_html/wf -rw-rw---- 1 _UID_ _UID_ 1464 Nov 22 22:54 ROOT/ellisons.org.uk/public_html/.htaccess -rw-rw---- 1 _UID_ _UID_ 282 Oct 17 23:19 ROOT/ellisons.org.uk/public_html/php.ini -rw-rw-r-- 1 _UID_ _UID_ 166 Aug 27 06:42 ROOT/ellisons.org.uk/public_html/siteDown.html drwxrwx--- 2 _UID_ _UID_ 2048 Nov 26 12:05 ROOT/ellisons.org.uk/public_html/b/_admin drwxrwx--- 2 _UID_ _UID_ 2048 Nov 26 13:29 ROOT/ellisons.org.uk/public_html/b/_cache drwxrwx--- 2 _UID_ _UID_ 2048 Nov 26 11:50 ROOT/ellisons.org.uk/public_html/b/_include drwxrwx--- 2 _UID_ _UID_ 2048 Nov 10 16:26 ROOT/ellisons.org.uk/public_html/b/_templates drwxrwxr-x 3 _UID_ _UID_ 2048 Nov 8 13:32 ROOT/ellisons.org.uk/public_html/b/themes drwxrwxr-x 4 _UID_ _UID_ 2048 Sep 9 19:38 ROOT/ellisons.org.uk/public_html/b/images drwxrwxr-x 4 _UID_ _UID_ 2048 Nov 2 21:00 ROOT/ellisons.org.uk/public_html/b/includes -rw-rw---- 1 _UID_ _UID_ 10416 Nov 22 23:36 ROOT/ellisons.org.uk/public_html/b/index.php lrwxrwxrwx 1 _UID_ _UID_ 10 Oct 17 23:40 ROOT/ellisons.org.uk/public_html/b/php.ini -> ../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/ellisons.org.uk directory. However, since the default access to all public_html directories is other:read+execute access, if I happen to know that somecompany.co.uk is hosted on Webfusion then I will be able to browse and read the file hierarchy /websites/LinuxPackage02/so/me/co/somecompany.co.uk/public_html 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?