lcas_lcmaps_gt_interface(8)

πŸ“¦
version 0.3.2 Β· 2 versions
, in ubuntu resolute, ubuntu stonking

πŸ’– lcas_lcmaps_gt_interface β€” the manual, bestie edition πŸ’–

okay so picture this: lcas_lcmaps_gt_interface(8) lives in the Site Access Control section of the manual, and she is literally the plug-in that runs LCAS and LCMAPS inside your Globus service. let's get into it 🫢


✨ NAME ✨

lcas_lcmaps_gt_interface β€” a Globus GSI-AuthZ plug-in that runs LCAS and LCMAPS. that's the whole job description, no notes πŸ’…


✨ SYNOPSIS ✨

lcas_lcmaps_gt_interface.so

lcas_lcmaps_gt4_interface.so

two whole .so files, both iconic, both doing the exact same vibe πŸ‘‘


✨ DESCRIPTION ✨

so this is a plug-in that gets loaded from a GSI-AuthZ capable Globus service. the feature dropped in Globus GT4 and is available for GT5 and GT6 too. the whole point of this call-out? authorize a user by optionally running the LCAS framework first, and then running the LCMAPS framework to map the user's credentials onto a Unix account. both LCAS and LCMAPS are plug-in frameworks themselves β€” the plug-ins are the ones doing the actual real work, they're the main characters fr.

some of these plug-ins can impose a certain policy on the user credentials, and others can off-load the decision to a centralized service so that service makes the call, or even hands you back an account mapping in the process. delegation, but make it authorization ✨

this plug-in gets dynamically loaded during every single interaction that needs an account mapping in the GSI-AuthZ interface of a Globus service. she has no configuration file of her own β€” nope, she's configured via environment variables plus the LCAS and LCMAPS configuration files. and you enable her for use in the GSI-AuthZ interface through the gsi-authz.conf file, by configuring it to call the function lcmaps_callout(), which you can do with gt4-interface-install(8). easy. periodt πŸŽ€


✨ ENVIRONMENT VARIABLES ✨

the whole personality is here, bestie. read carefully πŸ’–

  • LLGT_LOG_FILE β€” when this variable is set and it can actually be opened as a file, log output goes to that file instead of to syslog. and when either $LCAS_LOG_FILE or $LCMAPS_LOG_FILE is unset, it'll get set to this same file too. sharing is caring 🫢
  • LLGT_LOG_FACILITY β€” changes the default logging facility. use the name of (standard syslog) facility names. example: LOG_DAEMON, LOG_LOCAL1, etc. πŸ’«
  • LLGT_LOG_IDENT β€” can (optionally) be set as the syslog ident value. this is the identifying string in syslog for the current process. not using this option lets syslog (or one of the GT services) set these options instead. by default the syslog ident is set to the executable name. no cap.
  • LLGT_RUN_LCAS β€” set this to "no", "disabled" or "disable" to stop LCAS from running before LCMAPS. there's a matching ./configure option --enable-lcas that changes the default behaviour of running LCAS or not, but the $LLGT_RUN_LCAS environment variable can still influence the LCAS run. she always gets a say πŸ’…
  • LLGT_LIFT_PRIVILEGED_PROTECTION β€” normally the callout, after LCMAPS has finished, checks whether it's (still) running with root privileges (uid, euid, gid or egid) and fails if that is the case. this is to prevent erroneous configurations from silently resulting in a root-account mapping in services that don't have their own checks for this. when this variable is set, that check is disabled. this is NEEDED for services that:
    1. don't user switch, and run as root.
    2. services that expect only a username to be returned and perform the user switch themselves, e.g. the Globus GSI-OpenSSHd.
  • LLGT_CACHE_CALLOUT β€” set this to "no", "disabled" or "disable" to disable reusing the result of the localname callout for the userok callout. that means LCAS/LCMAPS authorization gets called twice for e.g. gsisshd. yeah. twice. 😭
  • LLGT_DLCLOSE_LCMAPS β€” set this to "no", "disabled" or "disable" to prevent calling dlclose() on the LCMAPS library. this might be needed as a workaround on RH5-based systems in an installation for gsisshd, when the use of PAM is enabled ("UsePAM Yes" in the /etc/gsissh/sshd_config). the underlying bug is a combination between the OpenSSL, VOMS and PAM libraries, which can trigger a segfault when VOMS is initialized twice. πŸ’€ not cute.
  • LLGT_DLCLOSE_LCAS β€” set this to "no", "disabled" or "disable" to prevent calling dlclose() on the LCAS library. this might be needed as a workaround on RH5-based systems. the underlying bug is a combination between the OpenSSL, VOMS and Globus libraries, which can trigger a segfault when VOMS is initialized twice β€” which can happen when LCAS is using a VOMS based plugin. normally this should not be needed, since LCAS is now dlclosed and terminated after LCMAPS. glow up achieved ✨
  • LLGT_NO_CHANGE_USER (deprecated) β€” deprecated in favour of $LLGT_LIFT_PRIVILEGED_PROTECTION. and just so we're clear: (deprecation does not mean non-functional anymore). she still works, she's just retired 🫢
  • LLGT4_NO_CHANGE_USER (deprecated) β€” deprecated in favour of $LLGT_LIFT_PRIVILEGED_PROTECTION. (depreciation does not mean non-functional anymore). same energy, different spelling in the original, iykyk πŸ’œ
  • LLGT_VOMS_DISABLE_CREDENTIAL_CHECK β€” the VOMS credentials get verified by the LCMAPS framework before any further processing happens in the plug-ins. LCMAPS has an API to enable or disable the verification of VOMS credentials, and this option disables that verification. a vanilla LCMAPS build will verify the VOMS credentials by default.
  • LLGT_VOMS_ENABLE_CREDENTIAL_CHECK β€” similar to $LLGT_VOMS_DISABLE_CREDENTIAL_CHECK, but this one enables the verification of the VOMS credentials, overriding the LCMAPS default setting of having VOMS credential verification disabled. a vanilla LCMAPS build verifies the VOMS credentials by default; the OSG build has it disabled by default. two builds, two vibes 🌸
  • LLGT_LCAS_LIBDIR β€” support for an alternative LCAS_LIBDIR as a run-time setting, by exporting something like $LLGT_LCAS_LIBDIR="/usr/lib/x86_64-linux-gnu/liblcas.so" ✨
  • LLGT_LCAS_MODULEDIR_SFX β€” when set, used as the suffix instead of the default /lcas when setting the $LCAS_MODULES_DIR variable based on the $LLGT_LCAS_LIBDIR variable. default /lcas. NOTE: current versions of LCAS do not yet use the $LCAS_MODULES_DIR variable. she's pre-gaming, basically.
  • LLGT_LCMAPS_LIBDIR β€” support for an alternative LCMAPS_LIBDIR as a run-time setting, by exporting something like $LLGT_LCMAPS_LIBDIR="/usr/lib/x86_64-linux-gnu/liblcmaps.so". must be an absolute path. setting this variable will also set the LCMAPS variable $LCMAPS_MODULES_DIR to the given libdir followed by either the default /lcmaps or the value of $LLGT_LCMAPS_MODULEDIR_SFX. multitasking πŸ’…
  • LLGT_LCMAPS_MODULEDIR_SFX β€” when set, used as the suffix instead of the default /lcmaps when setting the $LCMAPS_MODULES_DIR variable based on the $LLGT_LCMAPS_LIBDIR variable. default /lcmaps.
  • LLGT_ENABLE_DEBUG β€” if this variable is set, then the debugging messages logged at level LOG_DEBUG are passed to the log. the scope of this setting is only within the LCAS-LCMAPS-GT-interface. very much a local legend πŸ™ˆ

✨ INTERNAL ENVIRONMENT VARIABLES ✨

these ones are set internally, don't touch, they know what they're doing πŸ”₯

  • GATEKEEPER_JM_ID β€” an environment variable that's internally set to uniquely identify this gatekeeper and the job manager.
  • JOB_REPOSITORY_ID β€” similar to the $GATEKEEPER_JM_ID value, but its purpose is for the LCMAPS job repository plug-in.

✨ LCAS ENVIRONMENT VARIABLES ✨

the following list of LCAS environment variables is handled specially by the interface. she's got favourites πŸ’œ

  • LCAS_MODULES_DIR β€” default directory for LCAS to look for in plug-ins (not yet supported by LCAS). will be set based on the values of $LLGT_LCAS_LIBDIR and $LLGT_LCAS_MODULEDIR_SFX or their defaults.
  • LCAS_LOG_FILE β€” when set, LCAS logs there instead of to syslog. when unset, it gets the value of $LLGT_LOG_FILE when that one is set. when compiled with LCAS_LCMAPS_FORCE_LOG_TO_FILE defined, it gets set to /var/log/gt_lcas_lcmaps.log. πŸ“
  • LCAS_DEBUG_LEVEL β€” LCAS log level. default: 3.
  • LCAS_DB_FILE β€” location of the LCAS configuration file. default for the interface: /etc/lcas/lcas.db.

✨ LCMAPS ENVIRONMENT VARIABLES ✨

and now the LCMAPS side of the family, also handled specially πŸŽ€

  • LCMAPS_MODULES_DIR β€” default directory for LCMAPS to look for in plug-ins. will be set based on the values of $LLGT_LCMAPS_LIBDIR and $LLGT_LCMAPS_MODULEDIR_SFX or their defaults.
  • LCMAPS_LOG_FILE β€” when set, LCMAPS logs there instead of to syslog. when unset, it gets the value of $LLGT_LOG_FILE when that one is set. when compiled with LCAS_LCMAPS_FORCE_LOG_TO_FILE defined, it gets set to /var/log/gt_lcas_lcmaps.log. πŸ“
  • LCMAPS_DEBUG_LEVEL β€” for LCMAPS 1.5.0 (and newer) the value "5" corresponds to syslog LOG_DEBUG, "4" corresponds to LOG_INFO, "3" to LOG_NOTICE and so on. the LCMAPS default is to log up to LOG_INFO. numbers, but make it ✨vibes✨
  • LCMAPS_DB_FILE β€” location of the LCMAPS configuration file. default for the interface: /etc/lcmaps/lcmaps.db.

✨ RETURN VALUES ✨

  • True β€” the user is authorized and a local Unix account was procured. slay πŸŽ‰
  • False β€” no mapping was possible. 😭

✨ NOTES ✨

from version 0.3.1 onwards, the interface supports the 'sharing' service: it then expects an additional argument, (a PEM string) containing the credential on which the mapping should be based. extra arg, extra responsibility 🫢

from version 0.3.0 onwards, the interface tries to forward the requested username to LCMAPS (for version 1.6.0 and up). the mapping plugins can use this to support multiple username entries in the grid-mapfile, or to enforce pool account mappings to a specific pool account. she's a connector, not a gatekeeper πŸ’…


✨ BUGS ✨

if something's broken, please report any errors to the Nikhef Grid Middleware Security Team <grid-mw-security-support@nikhef.nl>. they're lovely, they'll help πŸ’–


✨ SEE ALSO ✨

gt4-interface-install(8), lcas.db(5), lcas(3), lcmaps.db(5), lcmaps(3) β€” go read the whole friend group, no skips 🌈


✨ AUTHORS ✨

LCMAPS and the LCMAPS plug-ins were written by the Grid Middleware Security Team <grid-mw-security@nikhef.nl>. absolute legends, no notes πŸ‘‘


and that's the whole page, bestie!! this one is from lcas-lcmaps-gt4-interface 0..., dated February 11, 2015, and it's filed under lcas_lcmaps_gt_interface(8). go forth and map those accounts πŸ¦‹πŸ’œβœ¨

πŸ“¦ where this page comes from