This page is actively misleading and does not represent the current state of HCoop. It appears to refer to some hybrid of our pre-AndrewFileSystem setup and early Peer1 setup.
Part of the reason hcoop is so swell is that we (try to) make it easy for members to take advantage of shared daemons. Of course, it's important that no one can take advantage of this to interfere with the services a daemon provides for others. This page focuses on how we do this for the particular case of data and configuration files associated with particular daemons but conceptually belonging to particular users.
There are two main things to watch out for:
One user shouldn't be able to exhaust available disk space through his configuration of a daemon. This would include getting a system user, e.g. the one that runs a particular database server, to exceed its disk quota or fill up the partition its data files live on. To achieve this goal, a common theme is that we try to keep all files with the potential to be large on /home and make sure that they belong to the group of the human user who we consider responsible for them. With this, we can use group quotas as single-point limits on disk usage.
- Through direct filesystem access, users shouldn't be able to break any daemons with respect to the services that those daemons provide for other users, though we don't care if users can hose their own services like this.
1. Static web sites
This one's easy. Users manage their own files and just need to make them readable by www-data, the Apache user.
2. domtool configuration files
Individual domain directories are basically extensions of users' home directories, permissions-wise, so again there are no problems.
3. Mailboxes
Users are given ownership of both their primary mailboxes (~/Maildir) and virtual mailboxes (in directory of choice under home directory). We're assuming that Exim and Courier IMAP are robust enough that errors in these mailboxes won't prevent delivery of mail to other mailboxes or prevent others from checking their mail.
4. Mailing lists
We modify the default Mailman set-up in the following ways:
Symlink /var/lib/mailman/[archives|lists] to /home/mailman/[archives|lists], where the real action is.
For a mailing list mylist@mydom.com owned by user me, we create it by running /usr/local/bin/listnew mylist mydom.com me somepasswd, which runs the following for each value of F in /home/mailman/lists/mylist, /home/mailman/archives/private/mylist, and /home/mailman/archives/private/mylist.mbox:
{{{chmod -R g+s F chmod -R g-rwx F chmod -R u-s F chown -R list.me F}}}
In other words, list, the Mailman user, owns the files. They have the human user's group, but this group is given no more permissions than the rest of the world gets. It's only there as a marker for /home group quotas. The directories are setgid, so that new files created belong to the human user's group.
Change the Mailman CGI scripts in /usr/lib/cgi-bin/mailman to be owned by list.list and to be setuid instead of setgid. These scripts already cry bloody murder if run by anyone but www-data, so this use of setuid should be secure. They let the CGI scripts run as the Mailman user itself, since belonging only to Mailman's group is no longer enough to access the list data.
5. SpamAssassin training
Everyone has write access to the shared folders where misclassified spam and ham should be deposited. This is definitely a security problem if someone wants to train SpamAssassin to mark legitimate and important messages as spam to harrass other users. Also, by copying files directly instead of going through IMAP, users may be able to screw up the folders in some way that impacts others.
6. MySQL databases (incorrect)
The databases of user me live in /home/mysql/me_*. Each of these directories is owned by mysql.me and is symlinked from the usual MySQL database location. There are no write permissions for the group, so me can't modify the database directly in an effort to confuse or crash MySQL; and, of course, all database files are counted towards me's group quota.
7. PostgreSQL databases (incorrect)
The databases of user me live in /home/postgres/me/. We use the new PostgreSQL's "tablespace" mechanism to make this more elegant than the MySQL set-up. Tablespaces are named containers for databases that are associated with particular roots in the filesystem. We give each user his own tablespace, with the usual ownership by his group, setgid, and no group permissions. me can't modify the database directly in an effort to confuse or crash Postgres; and, of course, all database files are counted towards me's group quota.