welcome: please sign in

Upload page content

You can upload content for the page named below. If you change the page name, you can also upload content for another page. If the page name is empty, we derive the page name from the file name.

File to load page content from
Page name
Comment
Last name of the current Debian Project Leader

Edit

DaemonFileSecurity

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:

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:

{{{chmod -R g+s F chmod -R g-rwx F chmod -R u-s F chown -R list.me F}}}

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.


CategorySystemAdministration CategoryOutdated