This page is from 2001/2002, when the Pool Accounts patch was developed at Manchester HEP for use by the EU DataGrid (now LCG/EGEE). The VDT Globus distribution used by LCG/EGEE now incorporates the patch as described below, and a slightly different version is used by GridSite's GRACE/gsexec system.

Pool Accounts patch for Globus

What is it?

The gridmapdir patch for Pool Accounts is a small modification of Globus 1.1.3 and 2.0's Security/gss_assist/gridmap.c or globus_gss_assist-2.0/gridmap.c file which enables the dynamic allocation of local unix usernames to Grid users. A pool of local accounts is created by the system's administrator using their normal account creation method, and these are leased to incoming Grid users by the modified functions of gridmap.c. Some mechanism outside of Globus (eg a hourly cron job) revokes the leases after a specified time and makes them available to other users.

(This is similar to the way DHCP allocates temporary leases on IP numbers from a pool.)

Where can I get it?

• gridmapdir.patch - to patch Globus 2.0 gridmap.c yourself

In Globus 2.0, you need to arrange for the modified gridmap.c to replace globus_gss_assist-2.0/gridmap.c and then rebuild Globus.

Alternatively, use the Testbed 1 Globus Distribution which we have contributed to the EU DataGrid. This includes the gridmapdir patch.

How does it work?

Normally, when a request for access is received, the Globus gatekeeper (or another Grid aware server such as sshd-gsi) attempts to find the corresponding local unix username in the grid-mapfile. This file lists pairs of certificate subjects (eg "/O=Grid/O=Globus/OU=hep.man.ac.uk/CN=Andrew McNab") and usernames (eg mcnab.) If no line is found for the current subject, access is denied.

With the gridmapdir patch, if the username field of a subject-username line is replaced by . then the gridmapdir_userid function is called: either to allocate a username from the pool of unleased accounts; or to return the username already leased to this subject.

Lease information is stored in the directory /etc/grid-security/gridmapdir (which can be a symbolic link to a gridmapdir elsewhere if required.) For each username in the pool, whether leased or not, an empty file exists in this directory with the same name as the user. When a username is leased, a hard link is made to it, with the same name as the subject. Subject names are stored using the "URL encoding" method - letters and numbers are unchanged, other characters are replaced by %HH where HH is their value in hexadecimal. (This is necessary since subjects include slashes and other unfriendly characters.)

To find which username corresponds to which subject and vice versa, the directory can be searched for links pointing to the same inode.

Since the function link(2) fails if a link with the new name exists, it is impossible to accidently overwrite the link of an existing subject name (for instance, if two processes are trying to write to the gridmapdir at the same time, on behalf of the same subject.)

To prevent two processes creating leases of the same username, gridmapdir_newlease checks that the link username has only 1 link. In case it is very unlucky and another process grants a lease between the calls to stat(2) and to link(2), gridmapdir_newlease stat's the username again, after it makes its link to make sure there are now only 2 links. If there are more, then it backs off and tries to find another unleased username.

This mechanism will work even for a gridmapdir on an NFS-shared filesystem, so it is possible to have consistent leases across a local cluster, even if many machines have their own gatekeepers, ssh-gsi or gsi-ftpd servers.

What does the sysadmin need to do?

The gridmapdir patch is intentionally very simple, with the minimum of alterations to Globus. This means that most of the configuration options that would be present in a more complicated system become choices the sysadmin makes using their existing (non-Grid) admin tools.

The first step is to make a pool of user accounts for use with gridmapdir. These can have any names you like, but for clarity, its probably best to use something like gpoolNNN where NNN is some number. There is no requirement that the UID's of the pool by contiguous. It is simplest to create the accounts with empty home directories, since they can easily be returned to this state when the lease expires. Consequently, /etc/profile and /etc/profile.d/* need to initialise the accounts with sensible defaults in the absence of any .profile

Next create an /etc/grid-security/gridmapdir directory, and create one file for each pool username. It's worth double checking there are no ordinary usernames in this directory at this point, so that they are not accidently leased.

(At Manchester, I've used a short script called addpoolusers to create the pool of usernames and to populate the gridmapdir.)

Finally, fill your normal grid-mapfile with the subject names you want to be dynamic. Instead of the username, use . as the second field on the line.

Each server (eg globus-gatekeeper or gsi_wuftpd) which will use the grid-mapfile must have the environment variable GRIDMAPDIR = /etc/grid-security/gridmapdir set. How you acheive this depends on how you start the service. However, it should normally be sufficient to insert the command export GRIDMAPDIR = /etc/grid-security/gridmapdir directly before starting the server.

The gridmapdir mechanism should now work. If leases are being created, subject names including lots of % characters, will appear in /etc/grid-security/gridmapdir and some of the local usernames there will now have 2 links when listed with ls -l

You also need to install a script to periodically expire leases. This must search /etc/grid-security/gridmapdir and remove subject files older than your expiration time (24 hours perhaps?) and clear their home directories. cleanpoolusers is an example of a script to do this, which can be put in /etc/cron.hourly

Multiple pools

You can also have more than one pool of users - perhaps with different disk quotas or with file access restrictions based on their unix group. To do this, create usernames which all have the same prefix (eg cms001, cms002, ... vs bbr001, bbr002, ...) and then instead of using . in the grid-mapfile, use .PRE where PRE is the initial string shared by all that pool of usernames (eg "/O=grid/DN=someone" .bbr) If this is done, then only usernames with the same prefix will be leased to that subject. Prefix matching is done with strncmp(3), which means that if .bbr was in the grid-mapfile, it would match both bbr001 and bbrwg001 since they both start with bbr