wiki:faq/files/privacy-standard-servers

Version 2 (modified by Jamie McClelland, 12 years ago) (diff)

--

How do I share and restrict access to my files?

This question comes up a lot. And, often there are as many variations of the question as there are questioners. 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).

Directories on a May First/People Link server

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.

General policy

The two main permissions a user has with regard to a file or directory on a server are: read access and write access.

Write access is relatively simple:

The general policy on read access 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 pieces 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.