Revision of Summary of Koumbit's work on ACLs and the client node type from Fri, 03/18/2011 - 21:46

We've done a good amount of work on Aegir this week, and so we felt we should document our progress here. This post exposes the big changes and how to make use of them, but also the implementation details of how this was done for programmers.

Koumbit's contributions

The general goal we're working on is to harden our shared hosting. Our first target was to simplify the work of our developers by allowing them to run drush as a regular user. This implied a lot of intermediate steps. We had to:

• figure out the right permissions - we settled on using POSIX ACLs
• reshuffle the client node type - this means API breakage and significant upgrade between rc2 and rc3, for which we have requested a freeze exception
• make user registration mandatory for emails to be sent; send registration emails to the logged in user instead of the client - as we have stopped using the Client email field. (Note: this also fixed our duplicate client issue)
• write ACL support for Provision so that those ACLs can be correctly created in the backend

All this work was released on drupal.org. For core, the patches are in the master branches of provision and hostmaster; we released a contrib module for the ACL support.

How to use ACLs to give your users shell access

With the above changes, you should be able to give shell access to specific clients through Aegir. To test this, you will need the following:

• update your Aegir install to run the master code
• install the provisionacl-1.0 release (or later) in ~/.drush
• save/create a client, and note down the "internal name" generated
• create a UNIX group on the server matching that "internal name"
• add users to that group
• verify or install a site owned by that client

The site should then have special ACLs on the settings.php and drushrc.php files:

Notice the "+" in the file listing - this marks files with an ACL. getfacl allows you to see exactly what that ACL is: in this case, the client named "anarcat" has read access to those files. This allows the anarcat user (member of the anarcat group) to run drush in the site without having to sudo to aegir:

Caveats

Aegir doesn't care about authorization in the frontend, however: you will still need to create the UNIX groups and map the shell users to them manually for this to work. This is the next iteration of development, where we'll be looking at integrating our LDAP server in the frontend, maybe with the new LDAP module.

Another issue is that giving users shell access like this will expose you to a full compromise of your aegir install unless you take extra steps. Those issues are documented in issue #762138 and although there's work underway in the provision_plesk module to fix this, it is not clear whether this provides complete security for now. We contributed a summary of the outstanding problems in that issue.

Koumbit is committed to fixing those issues for its own hosting, so rest assured we will be going ahead to fix this in the coming weeks.

Interesting Aegir APIs used

Those changes are an interesting way to understand the way Aegir works under the hood. The changes described above required both changes in the frontend and the backend of aegir, and we'll use this to present a few key principles of how the frontend and backend communicate with each other.

First is the distinction between tasks "context_options" and "options", which are two associative arrays used to carry information from the frontend modules to the backend drush commands. They serve two distinc purposes. "context_options" are options that are destined to be saved into the backend "context" (which is basically a drush alias mapped to a site, platform or server). A good example of that is a site's install profile or a platform's Makefile, that need to be recorded in the backend. The plain "options", however, are just one-time parameters that are not stored in the backend context.

In this patch, we switch the client_email between the two contexts: instead of being recorded in the backend (through the context_options), we just send it with this task (through the options) and discard it after. That's because we now send the email to the logged in user instead of the client so it makes no sense to keep that record. Instead, we store the client name which can be used by other modules, for example as done here in the provisionacl module.

The second interesting feat is how the install process works. You may already know that the backend executes tasks scheduled from the frontend, so there's a provision-install command that installs sites. Before doing that, however, it takes the data from the "context_options" array and stores that in the site context. Then provision-install comes around and installs the site according to the settings stored in the site context. However, now that we have removed the storage of the email in the context, we need to go through extra steps to make sure the installer has the right variables set.

The first step is to make sure we do not reference the context but the option passed on the commandline instead. Usually, we refer to context variables through the d() function, like this:

This would print the name of the current (also named '@self') context, that has been specified on the commandline. So for example, if this was injected in the provision install code, running:

would display:

This is a recurring pattern used in a lot of places all over the backend. Now for the email, we need to change that to use the option passed on the commandline, not the context. This patch basically does that, by using drush_get_option() instead of the magic d() function.

Because the provision-install command is split in two (to survive install failures better), we also need to send the setting to that secondary command, as done in this patch. This also shows how to invoke sub-commands and pass them parameters.

The full changes discussed here can be reviewed in this merge patch of the dev-refactor-client-962330 branch and the commits on the dev-noreg-mail-336068 branch.