How do I share and restrict access to my files?

If you have ever used ssh or sftp to login to a May First/People Link server, you've probably noticed that you can explore the entire server's directory structure. You can go all the way to the top of the filesystem hierarchy (know as the root directory), explore the server configuration directory (/etc) and even traverse the directories of other members (/home/members). At first glance, it may even appear that you can view every file and directory on the entire server.

In practice, however, you will find that certain files and directories are restricted. For example, /etc/shadow, which contains user passwords is restricted. So is every member's mail directory. You'll also find that the settings.php file containing the database username and password for Drupal installations is only read-able by the owner of that web site.

This page attempts to give an overview of how file sharing and permissions work on our standard servers to help members make smart decisions on how they want to share and restrict access to their files. There are a number of discussions proposing changes to our system (see below for links to those tickets).

General policy

The general policy is: open first, close second. In other words, rather than restrict users from reading all files and directories and then selectively opening the ones they are allowed to have access, we open access to everything, and then selectively restrict access to the files and directories they should not have access to. This approach is based on good security: by focusing on the few places that really need to be restricted we can more effectively maintain security than by attempting to secure much more than is necessary. It's also based on a principle of collaboration: we want our members to share with each other, to see who is on their server, and to have the opportunity to explore how our servers are configured and setup.

The details

When it comes to privacy, there are several areas of the file system to consider:

Server/system files

Nearly all files that are not in the /home/members directory are server/system related files. Members cannot write to any of these files, however, members can read almost all of them. There are only a handful of files and directories that contain security related information that are restricted.

Member directories and sites directories

Each members has a directory in /home/members. All members can read and explore these directories.

In each member directory, there are one more more site directories. For example:

• /home/members/mayfirst/sites/mayfirst.org
• /home/members/mayfirst/sites/members.mayfirst.org

Typically, each site directory has the following sub directories: logs, include, web, and users. Let's consider each one separately:

logs

the logs directory contains the web logs for the member's web site. It is not writable, not even by the member who owns the sites. It is only readable by users created by the member who owns the site.

include and web

these directories, by default, are readable by everyone. They can only be written to by users created by the member who owns site.

users

the users directory is the most complex. It contains a subdirectory for every user created by the member who owns the site (these are referred to as home directories). It is readable by everyone, meaning everyone can see a directory listing of the users. For users who were created prior to mid August 2008, the home directories in the users directory are also readable by everyone. In mid August 2008, we changed that policy so that home directories, by default, are only readable by the owner of the home directory. Home directories are only writable by the owner of the home directory.

Implications

Security cannot be evaluated on a simple scale ranging from bad security to good security. Instead, it is a system of trade offs that usually range between high security/low collaboration to low security/high collaboration. How you want to operate depends your goals and how they relate to these trade offs.

Following are a few general scenarios, along with implications and steps to take to modify your server environment to match them.

Lone operator

Many members have a single person who maintains their site. They alone have secure shell or sftp access to the site and they alone maintain it. While there may be a lot of sharing and collaboration that goes on in the web site - with multiple people logging via the web, there is only one person who is logging in via ssh and sftp.

The default MFPL setup should work fine in this scenario. However, there is one gotcha: if you created your user account prior to mid August 2008, your home directory may be world readable. This is only a problem if you make backups of secure information or database dumps to your home directory, in which case you should either ensure that those backups and database dumps are not world readable or remove world readale permissions from your home directory.

We share everything

You have many people in your organization who all have secure shell or sftp access and you want to be able to easily share files amongst yourself.

In this case, the default MFPL setup should work fine. However - if you user was created after mid August 2008, then no other users will be able to read their home directory. So, if you want to share access to your files, you will need to put the files in a location that all users have access to. The include directory is a good option for this purpose.

In addition, by default, users will be able to read the files uploaded by other users, but not be able to edit them. This restriction can cause a problem if, for example, multiple people are sharing the responsibility for managing a web site. If you are in this situation, please open a ticket to ask for assistance. Depending on what you are trying to accomplish, there may be other methods (ranging from sharing a single user account on the server between multiple people by using keys to using a revision control system like subversion).

We want to give some people limited access

Many people are interested in giving their own people restricted access to their server account. Exactly how you want to restrict the access and the needs will determine the best strategy to take.

• It's not about security, it's about simplicity. Some people don't need to limit what a restricted user can see or do, they are more interested in making it simple. If you have to change into all these different directories in order to upload a file or download a file, the user is going to get lost and give up. In this scenario, the best solution may be to use symlinks. A symlink is like a shortcut in Windows or an Alias in Mac OS X. When a restricted user logs in, they will immediately see their home directory. If you place a symlink in their home directory that points to the directory you want them to upload or download their files, they can accomplish that task quite easily.

• It's not about security, it's about user experience. For some people, planes won't fall of the sky if the restricted user sees directories they are not supposed to see, however, for whatever reasons, they just don't want their users to be exploring and see parts of their operation that, while not secret, are not widely publicized. At MFPL, there is no way to restrict a SFTP user to a particular directory, so achieving this approach is an absolute way is not possible (other options include building a web interface). However, you can request a separate hosting order that is only for sftp upload/downloads. The user may still traverse the entire MFPL file system structure and find your regular hosting order, however, if they only traverse their immediate file system, they will only see what you want them to see.

• It is about security - nobody should be able to see these files. If you have files on the server that should not be viewable, then those files should be secured even if you are not providing SFTP access. If you would like help/audit of your files to find out what is restricted and what is not restricted, please email us at support@mayfirst.org.

Additional questions

• But wait - I don't want other May First/People Link members (or folks that I give sftp access) to be able to browse my web directory! Remember: by default, everything in your web directory is available not just to people on our servers, but to the entire Internet. If you have files that should not be public, they should not be placed in your web directory. If you have a web application that is running PHP and is restricting access to files in your web directory based on a login information, you can similarly restrict read access to these files by people who have access to your server. Please email support@mayfirst.org if you are worried about files being public that should be private.

References to ongoing discussions

There are many members who have asked about how to properly secure files and directories. Thanks to everyone who has asked these questions publicly so we can more effectively figure out the best strategy. Here's a brief synopsis:

• World readable home directories - this discussion focuses on whether, by default, home directories should be world readable (the isssue in which we changed the policy in August 2008).
• How do share files between ssh/sftp users in a way that provides more fine grained control of what people can see? This question has taken several angles:
  • Chroot/restrict access to a particular directory - Should we add a feature so that certain ssh/sftp accounts are locked into a single directory when they login?
  • Using htaccess in conjunction with sftp
  • Important limitations of using htaccess in conjunction with sftp
  • Using webdav rather than SFTP
  • Deleting the main site alias - in other words, taken the make it simple approach
  • File send utility - pursuing a web application designed to send and receive large files