GLExec WN EMI 2 release notes

gLExec

Version 0.9.6

Bugfixes:

• umask was not reverted in non-linger mode.

Version 0.9.5

Bugfixes:

• Fix broken lcmaps-glexec.db produced by glexec-configure.sh script

Improvements:

• lower loglevel when homedir of payload does not exist from warning to info

Version 0.9.4

Bugfixes:

• specifying preserve_env_variables in the glexec.conf caused a segfault.

Improvements:

• Update location of wiki pages in man pages.

Version 0.9.2

Bugfixes:

• When either stdin, stdout or stderr is closed, a directory or opened in the wrong mode (readonly for out or writeonly for in) then gLExec (re)opens /dev/null instead.

Improvements:

• Install also manpage for glexec-configure

Version 0.9.1

Bugfixes:

• Signal handling code is greatly improved to prevent lockups.

Version 0.9.0

This version introduces several new features. The preferred and advised run-mode is linger mode with gLExec doing the userswitch. This is the most secure, simple and versatile run-mode. It means that LCMAPS should NOT run the posix_enf plugin.

New functionality

• epilogue functionality:
  
  • When a absolute path to a root-trusted file is specified as epilogue in the config file, it will be run after the payload has finished.
  • It can optionally run as a different user and/or group which then are also trusted concerning the binary writability.
  • It runs for a maximum time of epilogue_timeout (default 300 seconds) after which it is send a SIGTERM.
  • It will have /dev/null as stdin, stdout and stderr. It is for the epilogue itself to take care of its logging.
  • The epilogue process will run with the target environment.
  • In addition it will have a number of special other variables named GLEXEC_EPILOG_* which contain information about the payload process, calling account and target account is put in the environment for the epilogue process:

    GLEXEC_EPILOG_GLEXEC_CWD	startup directory of gLExec
    GLEXEC_EPILOG_GLEXEC_USER	calling username
    GLEXEC_EPILOG_GLEXEC_GROUP	calling primary groupname
    GLEXEC_EPILOG_TARGET_USER	target username
    GLEXEC_EPILOG_TARGET_GROUP	target primary groupname
    GLEXEC_EPILOG_GLEXEC_PID	gLExec process ID
    GLEXEC_EPILOG_GLEXEC_SID	gLExec session
    GLEXEC_EPILOG_GLEXEC_PGID	gLExec process group
    GLEXEC_EPILOG_GLEXEC_UID	calling user's uid
    GLEXEC_EPILOG_GLEXEC_GID	calling user's primary gid
    GLEXEC_EPILOG_GLEXEC_SGIDS	calling user's secondary gids, colon separated
    GLEXEC_EPILOG_TARGET_UID	target user's uid
    GLEXEC_EPILOG_TARGET_GID	target user's primary gid
    GLEXEC_EPILOG_TARGET_SGIDS	target user's secondary gids, colon separated
    GLEXEC_EPILOG_ARGC	argc of payload
    GLEXEC_EPILOG_ARGV<N>	argv of payload
    GLEXEC_EPILOG_TARGET_PID	payload process ID
    GLEXEC_EPILOG_TARGET_PGID	payload process group
    GLEXEC_EPILOG_TARGET_RC	payload exit code

  • When using process groups (default, use_setpgid=yes) both payload and epilogue will run in a separate process group equal to their PID.
  • A non-zero exit status of the epilogue will always result in a gLExec exit code of 202.
  • new options related to epilogue, see man glexec.conf(5)

    epilogue	(empty: no epilogue)
    epilogue_user	(default root)
    epilogue_group	(default root)
    epilogue_timeout	(default 300 seconds)

    in addition, also the sighandling options influence the epilogue.

• implementing signal handling:
  • most signals, are forwarded to payload or epilogue (when present).
  • SIGINT, TERM etc. will gracefully terminate the payload/epilogue by first sending a SIGTERM to the child process (group) and allowing a gracetime of term_delay before sending a SIGKILL. After the SIGKILL a second gracetime of kill_delay allows logging of the exit status. Note that since the lingering gLExec runs as root after the payload finishes, only root can forward signals to the epilogue.
  • handlers for SIGBUS, SIGFPE, SIGILL and SIGSEGV (and optionally SIGSTKFLT which normally should be unused) which only act when the signal comes from the kernel. They send a SIGTERM to the payload or epilogue process (group) and quit. No gracetime is wanted here. Similar behaviour happens for SIGABRT and SIGSYS except that these are typically not coming from the kernel and hence provide different information.
  • SIGPIPE is logged and ignored, SIGTTOU and SIGTTIN are directly ignored in order to allow jobcontrol.
  • gLExec is doing job-control on the payload: normally the payload will run in the foreground: When the payload suspends, gLExec will take back the tty. When the job resumes, the tty is returned to it. The payload can be forced to run in the background by either the -b cmdline option or the force_payload_background config option. SIGINT and SIGTSTP (typically ctrl-c and ctrl-z) give feedback on stderr.
  • gLExec normally will also forward the 'debug' signals SIGTRAP, SIGEMT, SIGVTALRM and SIGPROF, and additionally the realtime signals SIGRTMIN till SIGRTMAX, unless the extra_sighandlers option is set to no. Note that many modern debuggers including gdb work around the problem and seem to work fine even when installing sighandlers for SIGTRAP etc. Some of the realtime signals are used by valgrind, which prevents it from installing handler.
  • new options related to sighandling, see man glexec.conf(5)

    force_payload_background	(default off)
    term_delay	(default 5 seconds)
    kill_delay	(default 1 second)
    use_setpgid	(default yes)
    extra_sighandlers	(default yes)

• use of separate process group for the payload: this allows gLExec to signal the entire process group (e.g. SIGTERM). Signals will only be forwarded to the child itself. The feature can be disabled using the use_setpgid option.
• Closing of all open file descriptors in lingering gLExec process. This can be prevented by setting close_fds to 'no' in the config file.
• Calling user can disable writing/setting of payload proxy by setting GLEXEC_TARGET_PROXY to /dev/null (the sysadmin could already do this via the create_target_proxy option)

Several defaults are changed, the old behaviour is still configurable:

• When gLExec is doing the userswitch (advised and default setting) gLExec will run as calling user until the payload starts. At that moment, the payload will run as the target user, while the lingering gLExec will keep running as calling user. This allows the pilot user to send signals to the running gLExec. As soon as the payload finishes or a terminating signal is received, the lingering gLExec will become root and group 0.
  When really needed, the lingering gLExec can run as the target user (pre 0.9 behaviour) using the linger_as_payload option. This is not considered a safe setting and is strongly advised against.

• Logging defaults:
  • all (gLExec, LCAS, LCMAPS) builtin default loglevels are 4
  • a number of log messages are lowered in loglevel while improving the information in others.
  • gLExec now by default uses different syslog levels (diff_syslog_levels=yes).
  • LCMAPS logging in version 1.5 is much reduced and also split over syslog levels. Hence the builtin default of 4 allows reducing logoutput via syslog's own mechanism.
  • at the time of this release LCAS logging is not yet reorganized, hence it is advised to set the lcas_debug_loglevel to 0 (old default).

• LCAS/LCMAPS modules: when the {lcas,lcmaps}_libdir is set, gLExec now sets the {LCAS,LCMAPS}_MODULES_DIR variables to that libdir followed by /lcas or /lcmaps, in line with the EPEL standards. This suffix can be set in the config file using the lcas_moduledir_sfx and the lcmaps_moduledir_sfx.

Bugfixes:

• Lookup/use of lcmaps/lcas libdir only when existing absolute dir.

• When the config file is untrusted, gLExec reverts to builtin defaults, which often lead to a 'not-whitelisted' error to the user. The stderr message now mentions that it might be due to a permission issue of the config file.

• In addition to disabling voms checking, it can be enabled. This is needed when LCMAPS is build with a default set to no-voms-checking.

Build-time changes:

• default directories for LCMAPS and LCAS modules are now $libdir/lcmaps and $libdir/lcas. This can be overridden using the --with-lcmaps-moduledir-sfx (and likewise for LCAS) flags.

Installation & Configuration:

Known issues: None

LCAS

Version 1.3.17

Bugfix:

• lcas_findfile() was fixed for plugins, but also used for db file in lcas-plugins-basic. Functionality is now split

Version 1.3.16

Bugfix:

• Fix gsi handling code to prevent clash with globus symbols.

Version 1.3.15

Run time feature:

• New plugin search code, similar to the LCMAPS approach.
  1. Try to set get the environment variable LCAS_MODULES_DIR.
  2. On success: check if the provided plugin filename has an absolute path already, if not, prepend the $LCAS_MODULES_DIR value to the plugin and check if the file exists. If no file exists continue with 3. On failure: goto 3.
  3. Check if the provided plugin filename has an absolute path already, if not, prepend the LCAS_MOD_HOME #define value to the plugin path and check if the file exists. Use the LCAS_MOD_HOME #define. The defined value originates from the configure script and could be set there to the default or the --with-lcas-moduledir=DIR option. If this keeps failing, exit and trigger an LCAS initialization error.
  A new log line is printed in the log file to indicate what the LCAS plugin search paths are.

Build time feature:

• New configure option: --with-lcas-moduledir=DIR
  Sets the default search directory for LCAS modules to this value. Without the setting the default is relative to the (build) systems $libdir value: /usr/local/lib/lcas

Version 1.3.13

This version of LCAS and the related LCAS plugins introduces the following new features:

• fix a few minor segfault situations.
• Log file output is cleaned up a bit

• The LCAS framework and LCAS-Interface components are now integrated in each other
• adjusted to be able to use EPEL, EMI and gLite packages

AS_MOD_HOME

LCAS-PLUGINS-CHECK-EXECUTABLE

Version 1.2.4

Bugfixes:

• splitList() function used sprintf in unsafe way, rewriting function.

LCMAPS

Version 1.5.4

Bug fixes:

• Unbalanced quotes triggered an 'out of memory' error instead of an 'unbalanced quotes'.

Version 1.5.3

• Replace unprintable characters in logging strings with a '?'

Bug fixes:

• Fix a SEGV or ABRT in some interfaces due to incorrect storing of DN, which leads to freeing stack memory. Triggered in the lcmaps-without-gsi interface.
• Fix numerous unsafe constructions in logging, also fixes a SEGV

Version 1.5.2

Added a compile option in the Makefile.am to scope the externals of the library. This feature is mandatory for Debian.

Version 1.5.1

• Log messages that are sent to Syslog with the priority equal to LOG_EMERG, LOG_ALERT or LOG_CRIT will be downplayed as LOG_ERR. Old LCMAPS plug-ins used a numerical range of 0-5 and this basically means that they are able to cast an error message of type LOG_EMERG, while universally the LOG_ERR is meant of even less significant then a LOG_ERR. A warning will be written at LOG_WARNING to upgrade your plug-ins.

Version 1.5.0

• Changing all log messages to match the logging method used in Syslog and especially the log priority/levels.
• Fixed a problem when the "poolindex" was requested. It triggered a segmentation fault in two of the LCMAPS interface:
  • lcmaps_run_and_return_poolindex
  • lcmaps_run_with_pem_and_return_account
• Harmonized logging via the lcmaps_log(), lcmaps_log_debug(), lcmaps_log_time(), lcmaps_log_a_string() and lcmaps_log_a_string_debug() functions for both log file writing and syslog writing.
• Changed #define name DEBUG_LEVEL to CONF_LCMAPS_DEBUG_LEVEL
• Changed the default value for CONF_LCMAPS_DEBUG_LEVEL from 0 (LOG_ERR) to 4 (LOG_INFO).
• Harmonized the log line writing cut-off feature of log message between Syslog logging and logging to a file. This is based on the build in default and the LCMAPS_DEBUG_LEVEL environment variable value. Message that are cut-off are not even offered to Syslog anymore which speeds up the LCMAPS execution when the Syslog demon is hammered with info.
• The log line output is changed to show the environment value of LCMAPS_LOG_IDENT in each line. The LCMAPS_LOG_IDENT value is meant to be set by programs like gLExec to indicate that they are running LCMAPS. This is default in Syslog, but missing in logging to file.
• Log lines that log to file are prepended by the Syslog priority name.
  This allows easy filtering when needed.
• Harmonized the credential handling for all the external LCMAPS interfaces.
  The small functional differences between the different credential input differences are now gone. Interfaces used by gLExec (PEM based), GT4/5 GSI-Authz based, X.509 based and even string input handling are now equalized. This reenabled the verify-proxy plug-in to work from a GT4/GT5 service and enabled the Xrootd interface to work with more easier interfaces, and the PEM string interface from gLExec will now regain its full potential for VOMS handling.

   Example: {input credential} -> {stored to use by plugins}

   Globus gss_cred_id_t object in -> X.509 stuff(*) + VOMS structs + DN
   PEM string -> X.509 stuff + VOMS structs(**) + DN
   X.509 -> VOMS struct(**) + DN
   Other string based input -> string based input stored

   (*) is new.
   (**) differed in a detailed usage pattern.

• When the VOMS verification was disabled, either at run-time or after the build-in default is changed, i.e. --enabled-osg, the VOMS Generic Attributes were not successfully extracted. This is now fixed and plug-ins can use them also when the VOMS AC verification is disabled.

Version 1.4.34

Changes in the logging facility:

• All syslog() messages are lowered to LOG_CRIT or lower (and can't go below LOG_DEBUG)
• Various log functions were logging on a high priority, including the debug messages. This is to be lowered simulating the syslog() messages when writing to file.
• Not being able to write to a file descriptor results now in a syslog() message on LOG_CRIT. This was on stderr.

Version 1.4.31

Moved a lot more useless debugging output behind the LCMAPS_DEBUG option. Mostly because people who try to debug LCMAPS are not LCMAPS developers.

Version 1.4.30

Add the LCMAPS_DEBUG #define to be used to build a developer debugging version of LCMAPS. The released version will not expose the amount of pedantic logging output, even in LCMAPS_DEBUG_LEVEL = 5.

Version 1.4.27

LCMAPS framework:

• fixed a memory cleanup problem when using VOMS Generic Attributes.
• adds a SIGPIPE handler to print the caught signal, especially interesting when the VOMS api, SCAS-Client plugin or another plugin could trigger a SIGPIPE without handling it locally. The SIGPIPE handler will be set at the beginning of each run, and removed after each run, i.e. not in the initialization or terminate sequences.
• Fixed signed and unsigned conflicts in parsing routines when fullfilling rules and policys and recursion issues. This problem was hard to exploit, but a bug nontheless (unless somebody went beyond 2^31 plugins and policies)
• Fixed the poolindex interface to LCMAPS. A symbol would not have been resolved during run-time as it has been depricated last year. Only used by the Globus DAS/Workspace Service interfacing (to the best of our knowledge).
• Fixed a problem in the logging facility during the initialization phase. The value was always overridden by the next call. I've removed the previous overridden call, which might call for bug Savannah bug #61772.
• Found a more generic location for the printCredData function to log the credential data that has lead to a particular mapping decision mapping.

• (almost) all public functions are now prefixed with with "lcmaps_" to avoid symbol clashes
• Update for single lcmaps-interface for both lcmaps types.
• use enable_gsi_mode directly instead of lcmaps_gsi_mode
• Default paths in LCMAPS are set at build time. All hardcoded paths into /opt/glite or (in some places) /opt/edg are removed.
• /etc/lcmaps/lcmaps.db will be the new default path to a lcmaps.db file. Use ${LCMAPS_DB_FILE} to override or the ./configure options.
• Building lcmaps-without-gsi doesn't require Globus libraries during the build and linking of this LCMAPS flavor.
• LCMAPS ./configure new option --with-voms-prefix instead of --with-glite-location, no glite.m4 necessary, it's done using --libdir and system defaults

• API extentions:

Function	Description
int lcmaps_get_major_version (void);
int lcmaps_get_minor_version (void);
int lcmaps_get_patch_version (void);
lcmaps_disable_voms_attributes_verification	Disables the verification in the VOMS API
lcmaps_enable_voms_attributes_verification	Enables the verification in the VOMS API (default)
lcmaps_is_set_to_verify_voms_attributes	Will return the current setting to enable or disable the verification of the VOMS credentials by the VOMS API
lcmaps_run_with_stack_of_x509_and_return_account	LCMAPS runs receiving a certificate chain, containing at least an End-Entity Certificate. A list of policies may be provided. The allocated uid, gids and the poolindex will be returned to the calling application.

LCMAPS-PLUGINS-AFS

Version 1.4.1

- There is now a man page for the plug-in (copied from Debian packaging).

Version 1.4.0

- Changing the log messages to match the logging method used in LCMAPS version

 1.5.0, which will be using the Syslog native log priority/levels.

LCMAPS-PLUGINS-BASIC

Version 1.5.0

   -   Changing the log messages to match the logging method used in LCMAPS version
       1.5.0, which will be using the Syslog native log priority/levels.

   -   Fixed an error message that mentioned a gridmapdir was not available, while
       the grid-mapfile couldn't be found

LCMAPS-PLUGINS-C-PEP

Version 1.2.2

- New configuration option:

       --use-pilot-proxy-as-cafile
   With this new option the pilot proxy file in X509_USER_PROXY will also be
   used as if specified with the --cafile option. This is necessary for
   implementations using NSS for the SSL.

- New configure option --with-ssl-cipher-list=<cipherlist> to set the cipher

   list to be used for the SSL session. When unset no #define is passed.

- New configuration option:

       --ssl-cipher-list <cipherlist>
   With this new option a sysadmin can specify the cipher list to be used for
   the SSL session.  This feature is required to be used on systems that are
   forced to use a libcurl build against libnss, i.e. Red Hat Enterprise Linux
   6 (and derivatives) and Fedora 12 and up. The same holds true on
   installations have choosen the libcurl dynmically linked to libnss. A
   build-in default is used when this option it not set. The default setting
   is known to be compatible with OpenSSL 0.9.7 though 1.0.x. and GnuTLS.
   When unset, no explicit cipher list is passed to libargus-pep-c (which is
   pushed to the SSL library used by libcurl)

Version 1.2.1

- It is now supported to run this plug-in from an SSL- or GSS-based interface

   through LCMAPS. This included Xrootd, Globus gatekeepers, gridftpd and
   gsi-opensshd

Version 1.2.0

- Changing the log messages to match the logging method used in LCMAPS version

   1.5.0, which will be using the Syslog native log priority/levels.

Version 1.1.6

- Fixed and verified: GGUS ticket: 72752. The correct error message is no

 displayed in the log file: "Error: assert failed: setoptions for implicit ssl
 needs X509_USER_PROXY set"

Build methods and install details: - Rename lcmaps_config.h into lcmaps_c_pep_config.h and update

 AC_LCMAPS_INTERFACE to new-style. Still compatible with older LCMAPS apis.

- The new default install location for the module is $libdir/lcmaps, this was

 $libdir/modules.

To be tested to function properly: - Argus support for GSS/GSI and STACK_OF(X509)/X509 * LCMAPS interface users,

 like gatekeepers, gridftpd and gsi-opensshd on request by IGE. GGUS: 75568

LCMAPS-PLUGINS-TRACKING-GROUPID

Version 0.1.0

- Changing the log messages to match the logging method used in LCMAPS version

   1.5.0, which will be using the Syslog native log priority/levels.

- Fixed the initialization checks for the MINGID and MAXGID values to be a

   proper number. This was done by adding extra checks around strtol().

Plugin lcmaps-plugins-tracking-groupid (NEW) - GGUS ticket #69159: The goal of this new LCMAPS plugin is to preserve Batch System (like SGE and Condor) issued Tracking Group IDs and preserve them between the Pilot Job and Payload context in a Multi User Pilot Job environment. Especially useful for batch system that use the Tracking Group ID feature in Condor and Sun Grid Engine / Oracle Grid Engine batch systems.

tracking_groupid = "lcmaps_tracking_groupid.mod"

                  "--tracking-groupid-min MINGID"
                  "--tracking-groupid-max MAXGID"

LCMAPS-PLUGINS-VERIFY-PROXY

Version 1.5.2

- An internally restructured verify-proxy plugin fixing several memory

   handling problem. It solved several memory leakages and quite a lot
   potential segmentation fault situation.
   There should be no noticable change, besides the lowered memory leakage
   proper checking.

Version 1.5.1

No report

Version 1.5.0

- Changing the log messages to match the logging method used in LCMAPS

   version 1.5.0, which will be using the Syslog native log priority/levels.

- The plugin will fail to initialize when the configured -cadir or -certdir

   directory does not exist. This was a run-time error.

- Fixed the ability to use the plugin for life-time checking from a GT4 or

   GT5 service. The requirement for a private key MUST be explicitly disabled
   with either the configuration of "--only-enforce-lifetime-checks" or
   "--discard_private_key_absence". The internally used environment variable
   $VERIFY_PROXY_DISCARD_PRIVATE_KEY_ABSENCE is equivalent to the setting of
   "--discard_private_key_absence". The environment variable can be
   countered/muted by "--never_discard_private_key_absence".

- New feature to be able to REQUIRE the final certificate in a chain to be a

   LIMITED proxy.  Enable the option "--require-limited-proxy" to enforce
   this.
   This version DOES NOT WORK with RFC3820 limited proxy. This will be added
   in an update.

- Man page is now packaged with the source.

Version 1.4.12

The new certificate type detection function makes it possible to detect the proxy certificate type more cleanly and now properly distinghuishes RFC 3820 and old-style certificates reliable. A wrongly constructed chain is a rare occurance, but is now properly detected and will result in an X509_V_ERR_CERT_REJECTED or "certificate rejected" error code.

The certificate rejection is only triggered when the following #define is enabled: USE_STRICT_PATH_VALIDATION. Without it, the condition will be treated as a warning only seen on a verbose loglevel.

Also, the grid_verifyPathLenConstraints() function is now called when the X509_verify() reaches the final certificate in the chain in its verification cycle. This will dysect the certificate chain properly and trigger on the right errors.

A bunch of useless debugging messages are no longer visable in the log file. They can be revived when you upgrade the loglevel for more verbosity.

Version 1.4.11

Implemented my own Path Length Constraint check that is capable of checking both the Path Length Constraint in CA certificates and RFC proxy certificates. Fixing GGUS ticket 67040 - https://ggus.eu/ws/ticket_info.php?ticket=67040

Version: 1.4.10

Plugin lcmaps-plugins-verify-proxy: - Fixing path length constraint problem for TERENA eScience Peronsal CA users.

Version: 1.4.9

Plugin lcmaps-plugins-verify-proxy: - Fixed the Proxy Life Time Policy enforcement functionality. - Fixed the VOMS Life Time Policy enforcement functionality. - To cope with Subordinate CAs we have to extend the verification depth to be

 able to hold the certificate chain (could contain a lot of delegations) and
 all the CA certificate, which might not be added to the certificate chain
 itself but would still be lingering in the X509 CA directory lookup
 functions. OpenSSL uses a default depth of 9.

Resurrected an option with a different name: --only-enforce-lifetime-checks

When this option is set the verification routines are skipped to enforce the proxy and/or VOMS lifetime policies only. This is interesting for GT4/5 tools like GridFTPd and the Gatekeeper as they already perform full authentication on the SSL layer. In gLExec this plug-in MUST run in full mode.

LCMPAPS-PLUGINS-VOMS

Version 1.5.3

- Added manpages for the lcmaps_voms, lcmaps_voms_localaccount,

   lcmaps_voms_poolaccount, lcmaps_voms_poolgroup and lcmaps_localgroup
   plug-ins.

- Fix an 'invalid read' in valgrind (seems a bug in the gnu implementation of

   strspn())

Version 1.5.2

- Fixed a bug when the option -do_not_use_secondary_gids is set and no other

   is set. This was discovered during an upgrade on a CREAM CE by Massimo
   Sgaravatto.. The check was intented to cast an error when mutually
   exclusive settings where configured. In this case the settings were not
   mutually exclusive and falsely failed the initialization of the plug-in.
   The check has been removed.

Version 1.5.1

- Removed the gss_cred_id_t to X.509 conversion. The LCMAPS framework

   reliably takes care of this and taking the X.509 as a base (exclusive for
   the lcmaps_voms.mod, not the mapping plug-ins).

Version 1.5.0

- Changing the log messages to match the logging method used in LCMAPS

   version 1.5.0, which will be using the Syslog native log priority/levels.

- Added an initialization check to the voms localaccount plugin. The

   grid-mapfile must be stat()-able, otherwise trigger an initialization
   failure. Previously a run-time error would have been triggered.

- Added initialization checks to the voms poolgroup plugin. The groupmapfile

   and groupmapdir stat()-able, otherwise trigger an initialization failure.
   Previously a run-time error would have been triggered.

- A new option to the plugins "voms_localgroup" and "voms_poolgroup":

       --map-to-secondary-groups:
           When set all the VOMS FQAN to Unix Group ID mappings will be
           stored as secondary Unix group IDs. By default the first mapping
           will be stored as a primary Unix Group ID

- A new option to the plugins "voms_localaccount" and "voms_poolaccount":

       --add-primary-gid-from-mapped-account
           When set the primary Unix ID will come from the mapped local/pool
           account based on 'passwd' information on the account.
       --do-not-add-primary-gid-from-mapped-account
           When set the primary Unix ID will NOT come from the account and is
           expected to be set by another plug-in prior. The voms_poolaccount
           plug-in expects (by default) a primary Unix group id to be
           provided. The voms_localaccount could function without the primary
           Unix group id set. It is thereby advised to run a plug-in that will
           provided this information prior to these two plug-ins.
           Note for the voms_localaccount::
               This feature is equivalent to setting -use_voms_gid or
               --use-voms-gid
       --add-secondary-gids-from-mapped-account:
           When set the secondary Unix group IDs of the mapped account are
           added as mapped secondary Unix group ID results
       --add-primary-gid-as-secondary-gid-from-mapped-account
           The mapped pool/local account is looked up for its 'passwd'
           information and the associated primary Unix group ID is added to
           the mapping result as a secondary Unix group ID.
       The following combination of options is mutually exclusive:
           --do-not-map-primary-gid and --match-primary-gid-to-mapped-account
           --use-voms-gid and --do-not-map-primary-gid
           --use-voms-gid and --match-primary-gid-to-mapped-account
           --use-voms-gid and --add-secondary-gids-from-mapped-account

- New option to "voms_poolaccount":

       --require-primary-gid:
           This was the old default. The voms_poolaccount plugin expects to
           have access to an already mapped primary Unix group ID from a
           previously executed plug-in. The primary Unix group ID and the
           secondary Unix group IDs were used to form the poolindex entry for
           in the gridmapdir and poolaccount procurement process.
       --do-not-require-primary-gid:
           The new DEFAULT. The voms_poolaccount plugin does not expect a
           primary Unix group ID to be set by another plug-in. At the time of
           the poolindex construction and account procurement process from the
           gridmapdir the primary Unix group ID is *NOT* used when not yet
           set. If another plugin did set a primary Unix group ID, then this
           is going to be used too.
           Applying this setting provides the opportunity to us the
           "--map-to-secondary-groups" option to the "voms_localaccount" and
           "voms_poolaccount" and let the primary Unix group ID from the
           "--add-primary-gid-from-mapped-account" work as advertised.

Version 1.4.6

Moving the debug message more to the background into the debug stream.