Provided by: lcmaps-plugins-voms_1.6.2-2_amd64 
NAME
lcmaps_voms_poolaccount.mod - LCMAPS plugin to switch user identity based on VOMS credentials by pool
accounts
SYNOPSIS
lcmaps_voms_poolaccount.mod [-gridmapfile gridmapfile] [-gridmapdir gridmapdir] [--add-primary-gid-from-
mapped-account] [--do-not-add-primary-gid-from-mapped-account] [--add-primary-gid-as-secondary-gid-from-
mapped-account] [--add-secondary-gids-from-mapped-account] [--do-not-require-primary-gid] [--require-
primary-gid] [-override_inconsistency] [-max_mappings_per_credential maxmappingspercredential]
[-strict_poolprefix_match yes_or_no]
DESCRIPTION
This VOMS poolaccount acquisition plugin is a 'VOMS-aware' modification of the lcmaps_poolaccount.mod.8
plugin. The plugin tries to find a local account (more specifically a UserID) based on the VOMS informa‐
tion that has available from the LCMAPS, in particular the Fully Qualified Attribute Names (FQAN). The
account is acquired from an account pool. The accounts in the account pool must exist on the system, ei‐
ther locally or through a centralized account database, e.g. LDAP.
The gridmapdir directory is going to be used as a persistent and open mapping database. A pool is defined
as being a set of accounts following a particular pattern in their naming, i.e. pool001 or atlas001. In
the directory the plug-in will make a new filename build-up of the Subject-DN of the user, in URL-encode
form, followed by the name of the Unix groups that are already mapped by other plug-ins.
Example showing the output of ls -li:
1836080 -rw-r--r-- 2 root root %2fdc%3dorg%2fdc%3dterena%2fdc%3dtcs%2fc%3dnl%2fo%3dnikhef%2fcn%3doscar%20koeroo%20okoeroo%40nikhef%2enl:pool:group004
1836080 -rw-r--r-- 2 root root pool003
This filename is hardlinked to the mapped accountname. Creating this hardlink is designed to be an atomic
operation and verified to work on large installations serving multiple services from one NFS-share.
The VOMS credentials need to be available from the LCMAPS framework.
OPTIONS
-gridmapfile gridmapfile
This file must contain FQANs to (local) user account names. If this option is set, it will over‐
ride the default path of the gridmapfile. It is advised to use an absolute path to the gridmap‐
file to avoid usage of the wrong file(path).
-gridmapdir gridmapdir
A directory used for the mapping database.
--add-primary-gid-from-mapped-account
After the account is mapped, add the primary Group ID from the passwd-file/LDAP of the mapped ac‐
count as a part of the mapping result. Default is to not add the primary Group ID.
--do-not-add-primary-gid-from-mapped-account
After the account is mapped, explicitly avoid adding the primary Group ID from the passwd-
file/LDAP of the mapped account as a part of the mapping result.. Default is to not add the prima‐
ry Group ID.
--add-primary-gid-as-secondary-gid-from-mapped-account
After the account is mapped, add the primary Group ID from the passwd-file/LDAP of the mapped ac‐
count as a secondary Group ID as a part of the mapping result.
--add-secondary-gids-from-mapped-account
After the account is mapped, add the secondary Group ID from the groups-file/LDAP of the mapped
account as a secondary Group ID(s) as a part of the mapping result.
--do-not-require-primary-gid
This option will inspect the LCMAPS mapping store and fail enforce the existence of a primary
Group ID prior to running this plug-in. When enabled the plug-in will ignore the absence of the
primary Group ID prior to its own mapping sequences. This plugin or the next plug-in must map the
user's credentials to a primary Group ID in an LCMAPS plug-in execution policy. Default is: do
not require a primary GID.
--require-primary-gid
This option will inspect the LCMAPS mapping store and fail enforce the existence of a primary
Group ID prior to running this plug-in. When enabled the plug-in will fail before doing anything
on the grounds of the primary Group ID nonexistence. The solution is to make sure that another
plug-in is ensured to map the user's credentials to a primary Group ID. Default is: do not re‐
quire a primary GID.
-override_inconsistency
If the poolaccount is mapped from an URL-encoded Subject DN and Unix Group names to an account,
and when the gridmapfile states that this user needs to move to another pool, then the plug-in
will remap the user to the new pool. Without this option the plug-in will fail if an existing map‐
ping for the user credentials exist, but do not map the configured mapping pool.
-max_mappings_per_credential max_mappings_per_credential
This feature is deprecated. It was intended to work together with the Globus Dynamic Account Ser‐
vice/Workspace Service. This value indicates the maximum number of accounts a user, or more
specifically a set of credentials (=DN + FQANS), can be mapped to. Normally this number is 1.
But if each job should run under its own account the number should be increased. The leasename
(or poolindex) in this case looks like:
url_encoded(<DN>):gid1[:gid2[:gid3[...]]]:mapcount=<mapnumber>)
-strict_poolprefix_match yes/no
If this is set to 'yes', a line in the gridmapfile like <FQAN> .pool will result in accounts
matching the regexp pool[0-9]+. Otherwise it will be allowed to match pool.* (legacy behaviour).
RETURN VALUES
LCMAPS_MOD_SUCCESS
Success.
LCMAPS_MOD_FAIL
Failure.
NOTES
Since version 1.6.0 the voms_poolaccount plugin also takes the requested username (such as forwarded by
gsissh) into consideration. When present, the resulting poolaccount has to match it in order for the plu‐
gin to succeed. This requires LCMAPS version 1.6.0 or newer.
BUGS
Please report any errors to the Nikhef Grid Middleware Security Team <grid-mw-security-sup‐
port@nikhef.nl>.
SEE ALSO
lcmaps.db(5), lcmaps(3).
AUTHORS
LCMAPS and the LCMAPS plug-ins were written by the Grid Middleware Security Team <grid-mw-securi‐
ty@nikhef.nl>.
Stichting FOM/Nikhef February 25, 2013 LCMAPS_VOMS_POOLACCOUNT.MOD(8)