Need help locking down a WebFM installation and then enabling access

I have tested some more and installed RC5. I think I can now answer all of my above questions. I humbly submit my experiences so that they might be of help others. Caveat emptor!

The goal of this guide is to lockdown a WebFM installation. It is based on version 6.2-rc5 using a LAMP setup.

Users familiar with Drupal (or not) and new to WebFM should be aware of the following behaviours in WebFM.

1. When a user uploads a file he is set as the owner - permanently (Incorrect: see Comment #3). As the owner of the file, the user can also download the file always (using a direct link or webfm_send). This is true even if the user has no WebFM permissions in /admin/user/permissions or does not have a role that allows access to the file using the WebFM file specific permissions. The only way to prevent this is to re-upload the file as another user as far as I can tell.
2. In WebFM, role access rights can be hierarchical. In other words, being a member of role A can give access to files both in role A's WebFM root directory as well as B's root directory if the B's root directory is a sub-directory of A's.

WebFM defines a file access security model that is implemented in a module in Drupal. In other words it sits on the underlying security models of the Linux file system, Apache and Drupal. This requires that they be properly configured if the WebFM security controls are going to work properly.

Locking down the WebFM installation means preventing access to files in WebFM by unauthorised users. The strategy is to first deny all access and then to selectively enable access for authorised users.

1. Linux file system: follow the instructions in the README.txt for creating the 'WebFM root directory'. This allows public access to all files there.
2. Apache: Create a .htaccess file in the WebFM root directory with contents such as:
   

   order deny,allow
   deny from all
   

   This denies all access to the files using direct links for both authorised and unauthorised users. Even better if this can be placed in the Apache config without enabling the AllowOverride directive.
   http://httpd.apache.org/docs/2.0/howto/htaccess.html#when

3. Drupal: set download method to Public (this is the default) as stated in the README.txt. This simply hands over all file management to WebFM.
4. WebFM: Since Apache is now blocking access (download) of files using direct links, WebFM can be configured to use its webfm_send method to stream the files to the user via WebFM. Such a file URL looks like http://www.acme.com/webfm_send/20 where "20" is the uid of the file. There are two ways to associate a file to a node: an inline hyperlink to the file or an attachment to the node. Attachments use webfm_send per default. The hyperlink method may need some configuration to get the webfm_send method working. Specifically, the FCKEditor must be configured as described in /admin/help/webfm_popup.
   The Default File Permissions in the WebFM settings are important. Check 'Role View Access', 'Role Attach Access' and optionally 'Role Full Access' depending on how much trust there is between role users.

In is worth noting that because webfm_send uses the file uid, links to files are not affected when a file is moved or renamed in the File Manager.

Now WebFM can be configured to allow access to files. But first we need a use case. For demo purposes the following actors have been identified:

1. A WebFM admin to manage WebFM.
2. Power users that can upload and manage files as well as write articles and attach or link to files in WebFM. They can also read these articles as well as download associated files.
3. Authenticated read-only users that are authorised to access a subset of nodes and download/view attached/linked files.
4. Anonymous read-only users that are authorised to access a subset of nodes and download/view attached/linked files.

To implement the use case (focusing on the WebFM settings):

1. The WebFM admin can belong to the 'webmaster' role (for example). Drupal Permissions for this role need to be 'administer webfm' and 'access webfm' at a minimum. The 'access webfm' permission is needed because only the 'administer webfm' permission has the ability to create sub-directories for power users.
   Assign the webmaster role to the appropriate user. The WebFM configuration (/admin/settings/webfm) will ask for a root directory for the webmaster role which can be set to 'webmaster' (for example). The webmaster can then manage their own separate filespace.
2. Power users can belong to a role called 'power_users' (for example). Drupal Permissions need to be 'access webfm', 'view webfm attachments' and 'webfm upload'. The role also requires a root directory, e.g. 'power_users'. Power users can create content for themselves and for both authenticated and anonymous read-only users. This can be achieved by using different content types together with the Content Access module.
3. Authenticated read-only users that can read a node can also view/download the files that are attached to the node using WebFM. Drupal permissions need to be 'view webfm attachments'. However, inline hyperlinks using the same webfm_send url will fail. This is because the "Attach to Node" feature tells WebFM to allow access to the file if the user has access to the node. The only way to get hyperlinks to work is to also attach the file to the node as far as I can tell.
4. Anonymous users can also benefit from the same mechanism as described above for authenticated users. Another option is to use the WebFM "Public download" permission that can be set on a per file basis. This does not require the file to be attached to the node in order to use an inline link. However, this solution does not scale well as there is no way to sort out which files have been given this permission which have not which can be a security issue. The only way I can think of is to create a "Public" directory (for example) where all files with the "Public download" permission set are placed. One might be tempted to put a .htaccess file in the "Public" directory to allow anonymous file access but this would only work for direct links and it is too messy if a mixture of direct links and webfm_send links are allowed in nodes.

This fulfills the use case requirements while maintaining proper file access controls. The only weakness is the difficulty in managing files with the "Public download" setting enabled.

Feedback and corrections appreciated.

Best regards,
Kevin

Thanks for the feedback.

I was looking for issues regarding anonymous file access and I came across
http://drupal.org/node/475294#comment-1745206
Of course! The "anonymous user" role can also have the "access webfm" permission to download files that are inline links without the files also having to be attached to the node.

This means that #3 and #4 at the bottom of comment #1 are also incorrect. Using sub-directories to create subsets of files, the following root directory hierarchy can be used (following the above example):

power_users/<authenticated read-only users dir>/Public

This is a much more elegant solution since users that can browse files in the File Manager can clearly see which files are available to which roles. It is also an easy matter to change the security level of file by simply dragging-and-dropping a file into one of these directories.

So the question is, is the "Public download" file permission necessary since Anonymous users can have their own well-defined download area?

Giving the "anonymous user" role the permission "access webfm" so that anonymous users can view files that are hyoerlinks in nodes requires some extra thought.

Unfortunately, this permission will also allow anonymous users to browse files in the File Manager and so files in this root directory must have their permissions reduced to "Role View/Download" to prevent arbitrary changes to the files. (The "Role Attach" permission has no effect unless anonymous users can also create content).

But now the other roles in the hierarchy (power users and webmaster) that are supposed to manage and update these files can no longer do so because the files lack the "Role Full Access" permission.

Conclusion? Since the role permissions are at the file level, it is not possible to allow full access to one role and read-only access to another. The root directory hierarchy simply provides all-or-nothing file access for a role.

As a result, my original suggestion in Comment #1 still applies: to use a hyperlink to a file in the File Manager, the file must also be attached to the node - not a very elegant solution.

This analysis also highlights a security risk. If one is using a root directory hierarchy, the Default file permissions for uploaded files should not include "Role Full Access". Alternatively, users must be made to understand that a file uploaded to a sub-root directory confers full access to the file for that subordinate role.
A more conservative approach is to not have "Role Full Access" per default but to force users to enable it on a file by file basis.

Finally, it would be nice to be able to see which files have full access and which files are view/download or Public access. Lacking any bulk manipulation or filtering tools, a simple solutioin could be to use extra columns in the File Manager showing which permissions are enabled on each file.