NB: the functionality described in this page is not not yet in the SVN trunk. There is no release date yet, as the addressed use-case has changed in the meanwhile, and a working solution has been found in some cases.
Contents:
Introduction
The multi-user option is provided to allow creating sessions under usernames not recongnized by the system, i.e. not in the password file. Initially this option was mainly meant for testing purposes, facilitating the creation of sessions for different users without having to fully create them. However, a new use-case emerged from the experience of groups running on grids, which can be brought back to the multi-user case: this is the case where a real user exists per VO (Virtual Organization) while all members of such a VO have working areas under the {UiD,GiD} of their own VO. Support for this use-case is available in PROOF starting from version 5.25/0x. In this pages we describe how to use this functionality.
The xpd.multiuser directive
The multi-user mode is OFF by default and the xpd.multiuser directive is used to switch it ON. This directive allows also to define a template for the user working areas. For usernames not known to the system, these working areas will be owned by the effective user of the daemon.
An example of this directive is:
### Switch on multi-user.
### Create the user working areas named after the username under
### /users
xpd.multiuser 1 /users/
Advanced user mapping
By default, when the multi-user option is enabled, usernames not recognized by the system are mapped to the effective user of the daemon. PROOF provides the possibility to modify this default mapping via the directive xpd.umap; this directive allows to map a target username or VO name (see below) to a different effective user.
An example of this directive is:
### Map test user proof34 and VO proofvo to existing user 'alitest'
xpd.umap proof34 alitest
xpd.umap proofvo alitest
VO definition
Users are assigned to Virtual Organizations (VO) by the appropriate authorities. The information is typically included in the authentication credentials (e.g. in the X509 certificates). In the case this information is missing, PROOF provides the possibility to define VOs aout of group of users or groups or groups. This can be seen also as a way to simplify the global mapping to an (or to a few) effective user(s).
An example of this directive is:
### Define VO 'proofvo' with test users proof01, proof34 and proof87
### and the group 'proofteam'
xpd.vo proofvo proof34,proof87,proof01,g:proofteam
Note that any VO information found in the credentials has priority.