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
maxmappings
percredential
]
[
-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 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.
OPTIONS¶
- -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).
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 plugin 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-support@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-security@nikhef.nl>.