lcmaps_voms_poolaccount.mod (8)

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]

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 information 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, either 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.

-gridmapfile gridmapfile

This file must contain FQANs to (local) user account names. If this option is set, it will override the default path of the gridmapfile. It is advised to use an absolute path to the gridmapfile 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 account 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 primary 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 account 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 require 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 mapping 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 Service/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).

LCMAPS_MOD_SUCCESS

Success.

LCMAPS_MOD_FAIL

Failure.

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 plugin to succeed. This requires LCMAPS version 1.6.0 or newer.

Please report any errors to the Nikhef Grid Middleware Security Team <[email protected]>.

lcmaps.db(5), lcmaps(3).

LCMAPS and the LCMAPS plug-ins were written by the Grid Middleware Security Team <[email protected]>.