Last modified 12 years ago Last modified on 08/21/08 15:17:00

Proposed Change: Restriction of Policy Options


The purpose of this change is to achieve consistency in the support of mutiple roles, and to move towards a standard practice for authorization policies.

Support for Multiple Roles

Use cases exist in which a user needs to two or more different privileges using the same proxy. For example, there is a user who is accessing data from two different experiments in the course of the same job. The authorization policy for the SE is such that no single DN/Role combination allows simultaneous access to both storage areas.

gPlazma and gridftpdoor support the scenario by being able to consider multiple roles in the user's proxy. The user user may create a proxy containing a role for each of the experiments whose data is to be accessed. gPlazma sends a set of authorization records to gridftpdoor, one for each role found in the proxy. For a given transaction, the gridftp door tries each of the authorization records in order, until one is found that has the necesary privilege.

In ftp sessions this can lead to unexpected results if the user is not certain of the precise role which will be authorized for a given request. If a directory unexpectedly lacks write permissions for the user's first role, the write may be allowed for the second role. Besides the file then being written with possibly incorrect UID and GID, the users home directory may change, causing previously-written files to apperently disappear. The operation of changing the home directory has been removed from the version deployed on the site in question in order to amerliorate this consequence.

Restricting the Root Path

Regarding root paths, the current solution is to use during a session only the root path of the first authorization record which satisfies the access requirements. This, however, could lead to unexpected reults wherein combinations of UID-GID and root path that do not appear in the site's policies are invoked during a transaction. Therefore the solution is proposed in terms of authorization policy setup, that no conflicting root paths shall be allowed.

If the above modification is made permanent, it will remove some confusion in the user's experience. It may create confusion for site administrators, however, since currently it is not apparent that multiple root paths will not be honored. Furthermore, if a site does wish to configure multiple root paths, even with this knowledge they may not have a priori the usage patterns to guarantee that no conflict is created. Finally, it is possible that sites may already be set up with conflicting root paths, requiring a change in authorization policy that could require considerable effort to effect.

The first issue can possibly be handled by modifying the schema of policy configuration such that no policy can be written that has a conflict. This may result in increased complexity in the configuration files. Even then, the second issue above may make it impossible to write the required policy. So it may be that the only guaranteed solution is to have no rootpath at all. One then relies wholly on unix file permissions to enforce privileges. It may be necesary that the second issue is not resolved in the software; it will have to be assumed that sites know the usage patterns sufficiently. For the third issues, North and South American sites will be canvassed through the osg-storage mailing list to determine whether such a problem exists.

Restricting the UID/GID Mappings

The proposal is to simplify authorization policy options by allowing UID to be mapped by DN only, multiple GIDs to be mapped from the Role. Some dCache sites already follow this practice, and is the standard practice in some grids. This rule can mitigate some of the errors described above, since for the same user the UID can be used for access, even when the GID is incorrect.

The consequence of making this change will be to necesitate the changing of authorization policy on many sites. This can be eased by the creation of scripts which can automatically transform the configuration files. It is not clear that there can be universal tools to aquire the mappings from any associated compute element, for the methods may vary from site to site. Also, there will typically be many files presently on the pools whose ownership will change. This could entail a long process and raise questions of coherency during the transistion. Sites may find the risk of such large scale modifications unacceptable.

Directory Creation Masks

When each user has a unique GID, directory permissions must rely on GID to allow access by other users. Currently, the default directory permission is read-only. Therefore, to share directories for writing, some accomodation must be made. It is possible to change the permissions of a directory using an srm client call, but this would require changes to software being used to access storage. It is preferable to implement file and directory creation masks. If this is done at the level of a door, there may be conficts among the needs of different VOs. One solution would be to include the masks in the authorization record, e.g., UID, GIDs, root path, file creation mask, directory creation mask. Another solution is to implement in the doors some Chimera-like inheritance of masks, or to go directly to full support of ACLs.

Other Issues

Old Issues][gPlazmaOldIssues?


DN-UID/Role-GID Mapping Implemenation Notes

'Instructions for Testing'

Here are some instructions for testing the new DN->UID, Group/Role?->GID mappings in gPlazma. I will add a section to the dCache book once things are settled.

You may not want to do this kind of mapping for every user, so in grid-vorolemap choose the desired groups and have them map to a username, in this example "cmsmap", which will later be used as a handle to point to the new methods.

In grid-vorolemap

"*" "/cms/uscms/Role=cmssoft" cmsmap
"*" "/cms/uscms/Role=cmsprod" cmsmap
"*" "/cms/uscms" cmsmap

The new functions are invoked by a directive in storage-authzdb which declares that some entries in a record are names of methods rather than literal values. The methods are recognized by reflection. Otherwise, they are taken as literal values. The directive is the "dynamic" keyword in the first column, in place of the usual "authorize' word. In this example, storage-authzdb has a line

In storage-authzdb

dynamic cmsmap read-write dn_uidmap role_gidmap / /pnfs/ /

*This causes, for roles mapped to "cmsmap", the methods dn_uidmap to be used for the UID, and role_gidmap to be used for the GID. These methods use mapfiles in /etc/grid-security. They are grid-uidmap and grid-gidmap, respectively. Examples of mappings of DN to UID and Group/Role? to GID are as follows.

In grid-uidmap

"/DC=org/DC=doegrids/OU=People/CN=Ted Hesselroth 898520" 10501

In grid-gidmap

"/cms/uscms" 5091
"/cms/uscms/Role=cmssoft" 5095
"/cms/uscms/Role=cmsprod" 5098

If there are multiple roles in the proxy, gPlazma will authorize each of them and since in general they have different values of UID,GID, and rootpath, it will return a collection of UserAuthRecords. In the case where all the records have the same UID and rootpaths and differing GIDs, the records are coalesced into one record with a UID, an array of GIDs, and a rootpath. This is done automatically by the method


and then the returned collection has only one member. The values can be obtained from

UserAuthRecord.UID UserAuthRecord.GIDs UserAuthRecord.Root

I don't yet support a role mapping to multiple GIDs, such as in grid-gidmap

"/cms/uscms/Role=cmsprod" 5098,5099

but if needed this would be a small change.

Also, I haven't yet changed the classes to replace UserAuthRecord as suggested by Tigran.

These code changes have been committed to the trunk. They should not interfere with the current use of gPlazma.

Document created by Ted Hesselroth