glexec system administrator guide - nikhef · 2012-05-24 · using generic per-node pool accounts...

EUROPEAN MIDDLEWARE INITIATIVE

GLEXEC SYSTEM ADMINISTRATOR GUIDE

Document version: 1.0

EMI Component Version: gLExec 0.6 – 0.9

Date: May 24, 2012

Using generic per-node pool accounts or a sharedmap database

Contents

1Disclaimer

•

2Introduction

•

3Configuration

•

4 Moreinformation

•

Disclaimer

The preferred way of installing gLExec is using a central authorization service such as SCAS, Argus, orGUMS. The instructions below are for an installation without such a central service.

Introduction

A way to deploy gLExec on the worker node is by using (VO-agnostic) generic pool accounts that are local toeach worker node. This way, you can be sure that a gLExec'ed job does not "escape" from the node, and itlimits the number of pool accounts needed.

Configuration

For this configuration, you

create at least as many pool accounts as you have job slots on a WN• assign a worker node local gridmapdir (suggestion: /var/local/gridmapdir/ or/etc/grid-security/gridmapdir/)

•

create local pool accounts with a local home directory (suggestion: account names wnpool00 etc,and home directories in a local file system that has enough space, e.g., /var/local/home/poolwn00,etc.)

•

configure the lcmaps.db configuration used by glexec to refer to this gridmapdir•

If you like shared pool accounts, you can use a shared atomic state database (implemented as an NFSdirectory) to host the gridmapdir. All operations on the gridmapdir are atomic, even over NFS, and it scalesreally well (remember that NFS is still the file sharing mechanism of choice for many large installations)

Detailed documentation (currently only for 0.6.8-3) is given athttp://www.nikhef.nl/grid/lcaslcmaps/glexec/glexec-install-procedure.html.

Using generic per-node pool accounts or a shared map database - GridWiki

Using generic per-node pool accounts or a shared map database 1

More information

To test your setup then you can find more information on the page for Debugging hints.


More information 2

Using the SCASThe LCAS/LCMAPS GT4-interface for Globus GridFTPd, Gatekeeper and GSI-OpenSSHd and gLExec allshare the LCMAPS framework as their mapping back-end. It can be configured to use the SCAS clientLCMAPS plug-in. This will contact the SCAS service to trigger an authorization decision and, on a positiveresult, return a mapping result. This will then be input for the LCMAPS user mapping back-end of gLExec tocontinue.

Installation

Add the scas-client plugin to the set of RPMs on your machine. The SCAS client LCMAPS plug-in has arequirement on the SAML2-XACML2 C Library.

Configuration

Configure the LCMAPS You would add to /opt/glite/etc/lcmaps/lcmaps.db or/opt/glite/etc/lcmaps/lcmaps-glexec.db:

scasclient = "lcmaps_scas_client.mod" " -capath /etc/grid-security/certificates/" " -endpoint https://graszaad.nikhef.nl:8443" " -resourcetype wn" " -actiontype execute-now"

and the following policy execution flow at the end:

# policiesglexec_get_account:verify_proxy -> scasclientscasclient -> posix_enf

Note: This example assumes a verify_proxy and posix_enf plug-in to be configured in the same lcmaps.dbfile.

More information

To test your setup then you can find more information on the page for Debugging hints.


Using the SCAS 3

Batch System InteroperabilityWhen used on a worker node (in a late binding pilot job scenario), gLExec attempts really hard to be neutralto its OS environment. In particular, gLExec will not break the process tree, and will accumulate CPU andsystem usage times from the child processes it spawns. We recognize that this is particularly important in thegLExec-on-WN scenario, where the entire process (pilot job and target user processes) should be managed asa whole by the node-local batch system daemon.

Is your Batch System compatible with gLExec?

You are encouraged to verify OS and batch system interoperability. In order to do that, you have two options:

Comprehensive testing: Ulrich Schwickerath has defined a series of (partially CERN-specific) tests toverify that glExec does not break the batch system setup of a site. He has extensively documented hisefforts on the Wiki at https://twiki.cern.ch/twiki/bin/view/FIOgroup/FsLSFGridglExec. Note that theLocal Tools section is CERN-specific. If you use other tools to clean up the user's work area (such asthe $tmpdir facility of PBSPro and Troque), or use the PruneUserproc utility to remove strayprocesses, you are not affected by this.

•

Basic OS and batch-system testing can be done even without installing glExec, but just compiling asimple C program with one hard-coded uid for testing. This is the fastest solution for testing, but onlyverifies that your batch system reacts correctly, not that your other grid-aware system script will workas you expect.

•

Batch systems known to work

The following batch systems are known to be compatible with gLExec-on-the-Worker-Node:

Torque, all versions• OpenPBS, all versions• Platform LSF, all versions• BQS, all versions• Condor, all versions•

If you notice any anomalies after testing, i.e. the job will not die, please notify the developers at grid dashmw dash security at nikhef dot nl.

More information

Please have a look at the FAQs and misconceptions about gLExec page and when in doubt if your system iscompatible you can send an email to grid dash mw dash security at nikhef dot nl for more information andadditional for your particular situation.


Batch System Interoperability 4

LCMAPS Tracking GroupID pluginThe LCMAPS Tracking Group ID plugin preserves the Batch System issued Tracking GroupIDs during agLExec execution in a Multi User Pilot Job. Tracking Group IDs are added to batch jobs to be able to trackthem regardless if they escape the process tree.

Batch systems that use this feature are:

Sun Grid Engine (SGE, now known as the Oracle Grid Engine)• Condor-C batch system•

Other batch systems are known to have the feature, but it doesn't seem to be used in (known) Griddeployments:

LSF• Torque/PBS•

Contents

1 What's a TrackingGroup ID?

•

2 Process tree example• 3 gLExec's involvement• 4 Distribution• 5 LCMAPSconfiguration

•

6 CAVEAT 1• 7 CAVEAT 2• 8 CAVEAT 3•

What's a Tracking Group ID?

A tracking Group ID is a group ID issued by the batch system and attached to the first process that is the batchjob of a user. When a process spawns a child process, then the set of secondary GroupIDs is also inherited bythe process image copy of the fork() system call. All stray processes can be rounded up by the secondaryGroup ID that each of the user's process own.

Process tree example

Here is an example process tree on a PBS/Torque based cluster Worker Node. For illustration purposes allnon-relative processes are removed from the tree:

init- \_ pbs_mom | \_ bash


LCMAPS Tracking GroupID plugin 5

| | \_ 1337.stro.n /var/spool/pbs/mom_priv/jobs/1337.stro.nikhef.nl.SC | | \_ jobwrapper /opt/lcg/libexec/jobwrapper ./CREAM31337_jobWrapper.sh | | \_ CREAM31337_ -l ./CREAM31337_jobWrapper.sh | | \_ glexec /bin/bash payload.sh | | \_ payload.sh

gLExec's involvement

The problem is that gLExec ignores the tracking Group ID issued by the batch system. gLExec will useLCMAPS to decide to which Unix account the payload needs to be mapped. The Tracking Group ID plug-inwill make LCMAPS aware of the tracking Group IDs and preserve them when LCMAPS is building the Unixaccount mapping resolution.

Distribution

The distribution is officially distributed via EMI.

A man page and documentation is packaged with it.

LCMAPS configuration

The LCMAPS configuration file for my gLExec was changed to add this snippet in the top part:

trackinggid = "lcmaps_tracking_groupid.mod" "--tracking-groupid-min 1000" "--tracking-groupid-max 2000"

and at the bottom the flow of plugins to execute was altered to the following:

pluginexecpolicy:verify_proxy -> goodgood -> trackinggidtrackinggid -> posix_enf

As you can see, I've placed the trackinggid before the posix_enf plugin and after the good plugin. Replace thegood plugin with the regular set of sequences of plugin to make it work. If you have multiple of these blocks,place the 'trackinggid' right before each instance of the posix_enf.

CAVEAT 1

The gLExec version 0.8.1-1 checks if all newly mapped UserIDs, (primary) GroupIDs and all secondaryGroupIDs are resolvable to usernames and groupnames as a safety measure. You will not be hindered by thisdetail, but do note that other sites might experience problems. We're still discussion our options, but I take onit is that the UID and primary GID can perfectly be checked, but the secondary GID check and failure is afalse-positive and should be regarded as a pedantic check that hinders Tracking GID deployments.


Process tree example 6

GLExec version 0.8.10 solves this problem by relaxing the check on the mapped (target) secondary GroupIDs.

CAVEAT 2

I might have made some typos and style mistakes in the documentation and man pages. These will be fixed ina next release.

CAVEAT 3

We have not tested this on an AFS site. We know that AFS issues secondary GIDs itself. We have not testednor assessed (yet) what the potential security implications could be of preserving the AFS issued secondaryGIDs with respect to accessing the AFS token from the MUPJ's payload process.


CAVEAT 1 7

Deployment Scenarios in EGEE and OSG

Deployment scenarios in EGEE and OSG

The way gLExec is installed depends a bit on the chosen scenario and the way authorization in done in yourinfrastructure. Have a look at these installation and deployment guides for more information:

gLExec installations in Open Science Grid• YAIM supported installation in EGEE, both YAIM site-info.def variables and a specific section forgLExec on worker nodes installed with YAIM

•

Installing gLExec on the worker node (setuid) manually is described here.• See also the gLExec Service Reference Card.•


Deployment Scenarios in EGEE and OSG 8

Secure installation considerationsTo prevent a wrong installation of gLExec, which could lead to easy exploitation of the computer system, anoutside source must be able to verify the installation. Consider the use of tripwire, rpm --verify <rpm packagename> or something.

At the moment the packages that we produce are without the setuid bit on root. This means that an adminwould need to run YAIM or the chmod command manually to get the setuid bit enabled on root. Because thedeployment needs this post installation manipulation on the executable the rpm --verify (and Debian packageequivalent) will inherently fail, because not only the hash of the binary but also the file permissions areverified.

Note that it is impossible for gLExec to provide a reliable self-contained test to signal that its binary is, forexample, world writable: if it is world writeable a potential attacker can replace the binary and thus fake thetest. On the other hand, on Linux systems and most Unix system the setuid-root bit is stripped when the imageis rewritten, which largely solves this specific problem.


Secure installation considerations 9

Debugging hintsHere are some useful things to check and mention when contacting us for help which should help you shoot(some) trouble.

Contents

1 Check the version of the gLExec version:• 2 The special "glexec" account• 3 Check the file permissions of the gLExec executable.

3.1 Versions up to 0.6.8-3♦ 3.2 Version 0.7.0-2 and higher♦

•

4 Before continuing with testing: The gLExec Exit Codes and the Environment variables• 5 Execute with exported GLEXEC_CLIENT_CERT and exported X509_USER_PROXY, with thefull path

•

6 Is the user account that tries to use gLExec whitelisted?• 7 Squashing root?

7.1 NFS♦ 7.2 nosuid♦

•

8 Example test script for gLExec•

Check the version of the gLExec version:

/opt/glite/sbin/glexec -v

The special "glexec" account

A glexec Unix account must be present on the system. Both the username and the groupname are treatedspecial by gLExec.

Check if the account exists and that it has (only) a glexec group associated to the username:

id glexec

Expected answer (note: numbers are site/node specific):

uid=55811(glexec) gid=2503(glexec) groups=2503(glexec)

Or (without the secondary GID):

uid=55811(glexec) gid=2503(glexec)

Important: Note that the account name glexec resolves for both the username and the (primary) groupname ofthe glexec account.


Debugging hints 10

Check the file permissions of the gLExec executable.

For all run-modes of gLExec, the gLExec must be executable for all users.

Versions up to 0.6.8-3

For running gLExec in setuid mode, preferably use the following mode (setuid and setgid):•

-r-sr-sr-x 1 root root 12345 2010-02-29 12:34 glexec -rw-r----- 1 root glexec 123 2010-02-29 12:34 glexec.conf

In case setgid is not possible, preferably use the following mode (only setuid):•

-r-sr-xr-x 1 root root 12345 2010-02-29 12:34 glexec -rw-r--r-- 1 root glexec 123 2010-02-29 12:34 glexec.conf

For running gLExec in logging only mode, preferably use the following mode:•

-r-xr-xr-x 1 root root 12345 2010-02-29 12:34 glexec -rw-r--r-- 1 root glexec 123 2010-02-29 12:34 glexec.conf

Note that these settings are also possible on a NFS mount.

Version 0.7.0-2 and higher

For running gLExec in setuid mode, preferably use the following mode (only setuid):•

-rws--x--x 1 root root 12345 2010-02-29 12:34 glexec -r-------- 1 glexec root 123 2010-02-29 12:34 glexec.conf

For running gLExec in logging only mode, preferably use the following mode:•

-rwx--x--x 1 root root 12345 2010-02-29 12:34 glexec -r--r--r-- 1 glexec root 123 2010-02-29 12:34 glexec.conf

Note that these settings are also possible on a NFS mount.

Also note that YAIM will still install gLExec with either the setuid-and-setgid or logging-only-mode settingsof the previous versions which are still valid, and are also possible on an NFS mount.

The non-YAIM only-setuid set of permissions of the previous versions no longer works: when the setuid-rootbit is on, the glexec.conf file should be at most readable by the group glexec, i.e. not readable by others andeither not group-readable or have group glexec.


Check the file permissions of the gLExec executable. 11

Before continuing with testing: The gLExec Exit Codes and theEnvironment variables

The following pages might hold interesting to glance through before proceeding with your debugging:

Proxy file handling in gLExec: All the details about the environment variables used by gLExec.• Exit codes of gLExec: All the details about the exit codes of gLExec.•

Test the exit codes by printing them on the shell by showing the value of $? Example:

/opt/glite/sbin/glexec /usr/bin/id -a; echo $?

Execute with exported GLEXEC_CLIENT_CERT and exportedX509_USER_PROXY, with the full path

See Proxy file handling in gLExec for the purpose of these environment variables.

export GLEXEC_CLIENT_CERT=`pwd`/mkproxy-x509-vomsexport X509_USER_PROXY=`pwd`/mkproxy-x509-voms

Is the user account that tries to use gLExec whitelisted?

Method 1.: the calling account is a member of the 'glexec' primary or secondary group.

Method 2.: the account or the pool is whitelisted in the glexec.conf. See the Man pages of gLExec for moredetails on the whitelist options.

Note: when gLExec fails with a 'user not whitelisted' error, this might be caused by an unreadable glexec.conffile: in case the glexec.conf file is unreadable, gLExec uses its buildin defaults, including whitelisting onlyunix accounts which are member of the glexec group. Check the file permissions of the gLExec executable.

Squashing root?

gLExec is capable of being installed on a root-squashed NFS file system. We even support the glexec.conf tobe installed on a root-squashed file system.

NFS

The NFS root-squash will squash all the effective root privileges of a process on the kernel level. gLExec hasa safe way around this security measure, it lowers itself to the glexec account on the system to read theglexec.conf file. Besides keeping root-squash there, it adds the security measure that gLExec isn't readinganything with elevated privileges.


Before continuing with testing: The gLExec Exit Codes and the Environment variables 12

Ensure that you install gLExec with the advertised privileges from our Wiki (the latest YAIM configurationsshould support this too) to make use of this method.

nosuid

Running gLExec in the normal (or full) mode requires it to be installed with functional setuid bits on thebinary. Therefor the file system of where the gLExec binary is installed can not be mounted with the optionnosuid.

The gLExec binary is a root-owned setuid-bit enabled binary, like sudo and su. In the normal run modegLExec requires the setuid functionality to be functional. The gLExec binary must there for be installed on afile system that does not make use of the optional nosuid setting.

The error message that you might encounter is:

[gLExec]: The user, uid=X, is not whitelisted. The calling user account is not privileged to execute and use gLExec.

The cause for the error message is because gLExec has a build-in feature to trust all users with the glexecsecondary GID, this is why it tries to do its work and fails with this message and a 203 exit code. Looking atthe file settings for both the {/opt/glite}/sbin/glexec and {/opt/glite}/etc/glexec.conf could come to theconclusion that everything is ok. If so, then you should check the file system and it's mount options.Non-POSIX file systems might not have a setuid capability or the file system of the {/opt/glite}/sbin/glexecbinary might have the setting nosuid. Test this with the mount tool:

[root@asen ~]# mount | grep /opt/dev/sdb1 on /opt type ext3 (rw,nosuid,nodev)

Example test script for gLExec

Testing basic functionality:

#!/bin/sh

TESTPROXY=/tmp/x509up_`id -u`

export GLEXEC_CLIENT_CERT=$TESTPROXYexport X509_USER_PROXY=$TESTPROXY

/opt/glite/sbin/glexec /usr/bin/id -a ; echo $?

Testing with the transfer of a specific proxy file:

#!/bin/sh

TESTPROXY=/tmp/x509up_`id -u`


NFS 13

export GLEXEC_CLIENT_CERT=$TESTPROXYexport X509_USER_PROXY=$TESTPROXYexport GLEXEC_SOURCE_PROXY=$TESTPROXY

/opt/glite/sbin/glexec /usr/bin/id -a ; echo $?

Testing multi-user Pilot Job scenarios:

#!/bin/sh

VOMSINFO=`which voms-proxy-info`

PILOT_PROXY=/tmp/x509up_`id -u`TARGET_USER_PROXY=`pwd`/other.proxy

export X509_USER_PROXY=$PILOT_PROXYexport GLEXEC_CLIENT_CERT=$TARGET_USER_PROXYexport GLEXEC_SOURCE_PROXY=$TARGET_USER_PROXY

$VOMSINFO -all/opt/glite/sbin/glexec $VOMSINFO -all


Example test script for gLExec 14

GLExec Epilogue FunctionalityStarting from version 0.9 gLExec can optionally run an epilogue executable after the payload has finished.

Contents

1 General• 2 Logging• 3 Configurationoptions

•

4 RuntimeEnvironment

•

5 Security• 6 Exampleusage

•

General

In linger mode, gLExec can optionally run a trusted executable, intended to clean up the payload environment.Whether it will run is triggered by the glexec option epilogue. The option should point to the absolute path ofa trusted executable: it must not be possible for anyone except the root user (or the epilogue_user and/ormembers of the epilogue_group when set) to change the executable. It will run as uid/gid 0,0 (unlessepilogue_user and/or epilogue_group are set). If it does not finish within a set epilogue_timeout, it will besend a SIGTERM. For proper functioning it is advised that gLExec will do the userswitch (instead ofLCMAPS).

If the epilogue fails for whatever reason, gLExec will return either with a 202 exit code (internal gLExecerror) or potentially a 204 (e.g. when the epilog itself returned a 201-204 range exit code).

Logging

The epilogue runs with stdin, stdout and stderr all attached to /dev/null. There is no special loggingfunctionality implemented and this is left to the developer of the epilogue code.

Configuration options

The epilogue can be configured using the glexec.conf settings

epilogue when set, the name of the trusted binary or script to run. Needs to be a absolute canonicalpath

epilogue_user When set, the epilogue will be run with this user identity. In addition this user is allowedto have write permission for the epilogue executable (i.e. is trusted). This option can onlybe used when gLExec does the userswitch. It can be useful if the script is located on an


GLExec Epilogue Functionality 15

NFS with root squash. Default: root.

epilogue_group

When set, the epilogue will be run with this group identity. In addition members of thisgroup are allowed to have write permission for the epilogue executable (i.e. are trusted).When unset, the executable will be run with GID 0 and no group will be trusted. Thisoption can only be used when gLExec does the userswitch. It can be useful if the script islocated on an NFS with root squash.

epilogue_timeout The epilogue executable will run for at most this timeout in seconds, before being sent aSIGTERM (and SIGKILL). Default: 300 seconds.

Runtime Environment

The epilogue runs with the same cleaned environment as gLExec sets up for the payload, with a number ofadditional variables, all starting with GLEXEC_EPILOG_. Any variables setup before gLExec starting withGLEXEC_EPILOG_ will be cleared before the epilogue is run.

GLEXEC_EPILOG_ARGV<N> argv of payloadGLEXEC_EPILOG_GLEXEC_USER calling user usernameGLEXEC_EPILOG_GLEXEC_GROUP calling user's primary groupnameGLEXEC_EPILOG_GLEXEC_UID calling user's uidGLEXEC_EPILOG_GLEXEC_GID calling user's primary gidGLEXEC_EPILOG_GLEXEC_SGIDS calling user's secondary gids, colon separatedGLEXEC_EPILOG_TARGET_USER target user's usernameGLEXEC_EPILOG_TARGET_GROUP target user's primary groupnameGLEXEC_EPILOG_TARGET_UID target user's uidGLEXEC_EPILOG_TARGET_GID target user's primary gidGLEXEC_EPILOG_TARGET_SGIDS target user's secondary gids, colon separatedGLEXEC_EPILOG_GLEXEC_PID lingering gLExec process IDGLEXEC_EPILOG_GLEXEC_SID lingering gLExec session IDGLEXEC_EPILOG_GLEXEC_PGID lingering gLExec process groupGLEXEC_EPILOG_TARGET_PID payload process IDGLEXEC_EPILOG_TARGET_PGID payload process groupGLEXEC_EPILOG_TARGET_RC payload exit code

Security

In order to prevent tampering with the epilogue binary or script, the permissions need to be such, thatonly the root user and optionally epilogue user, has write access to the file or one of its path members(it is "trusted-root").

•

GLExec becomes immune to signals from any user but root.• It is important to note that writing a epilogue should be done with utmost care:

it will be ran (normally) by root user♦ it is triggered automatically♦

•


Configuration options 16

blindly killing all processes from the payload user can kill good processes♦ ...♦

Logging should be done in a secure way, e.g. to either syslog or to a trusted file location.•

Example usage

Providing a catch-all example script is not possible as this heavily depends on site details. Sites might want tohave a look at Nikhef's reaper script, intended to clean up daemonized processes after a grid job has finished.

Another example script that can be used after necessary changes to clean up remaining subprocesses after thepayload has finished. It assumes that gLExec uses process groups (default behaviour).

#!/bin/sh# Example epilogue script for use with gLExec 0.9.## DISCLAIMER: THIS SCRIPT IS INTENDED AS EXAMPLE CODE ONLY# DO NOT USE WITHOUT PROPERLY UNDERSTANDING WHAT IT IS DOING AND MAKING ALL NECESSARY CHANGES.## Nikhef and/or the author do NOT except any liability for any damage that might occur when using this script.## Author: Mischa Salle <[email protected]>#

# Location of logfileLOGFILE=/var/log/glexec/epilog.log

# Some useful variablesLOGDIR=$(dirname $LOGFILE)PROG=$(basename $0)FMT="%b %e %H:%M:%S $(hostname) $PROG[$$]: "EPIL_UNAME=$(whoami)EPIL_UID=$(id -u $epil_uname)

# Create log directory and file if not exist and make sure at least logfile has# right permission[ ! -d $LOGDIR ] && { mkdir -p -m 0700 $LOGDIR || exit 1; }[ ! -f $LOGFILE ] && { touch $LOGFILE || exit 1; }chmod 0600 $LOGFILE || exit 1

# Log general informationecho $(date +"$FMT") "Running as uid $EPIL_UID ($EPIL_UNAME) for" \ "glexec $GLEXEC_EPILOG_GLEXEC_PID," \ "payload $GLEXEC_EPILOG_TARGET_PID" \ "uid $GLEXEC_EPILOG_TARGET_UID ($GLEXEC_EPILOG_TARGET_USER)" >> $LOGFILE

# Get process IDs of all processes in the payload process group running as the# target user. Note: this is no guarantee to catch all processes as the payload# could have started a new process group.pids=$(ps -opid=,pgid= -u $GLEXEC_EPILOG_TARGET_UID|grep " ${GLEXEC_EPILOG_TARGET_PGID}$"|cut -c-5)if [ -n "$pids" ]; then echo $(date +"$FMT") "Sending SIGKILL to PIDs: `echo $pids`" >> $LOGFILE kill_output="$(kill -9 $pids 2>&1)"


Security 17

if [ $? -ne 0 ];then # Log error but do not fail epilogue on it echo $(date +"$FMT") "$kill_output" >> $LOGFILE fifi

# 1 second gracetimesleep 1

# Log remaining process IDs of processes running as the payload user: these# might have come from this or other jobsrem_pids=$(ps -opid= -u $GLEXEC_EPILOG_TARGET_UID)if [ -n "$rem_pids" ];then echo $(date +"$FMT") "Remaining processes from uid" \ "$GLEXEC_EPILOG_TARGET_UID:" $rem_pids >> $LOGFILEelse echo $(date +"$FMT") "No remaining processes from uid" \ "$GLEXEC_EPILOG_TARGET_UID" >> $LOGFILEfi

# All doneexit 0


Example usage 18

Need to Know's

Contents

1 The difference between setuid and non-setuid (logging-only)mode

•

2 Safety features• 3 How to work with the gLExec secured environment• 4 More information•

The difference between setuid and non-setuid (logging-only)mode

The gLExec executable is installable in two ways, with and without the setuid (file system) bit on root. Withthe setuid-bit enabled on root, this effectively means that gLExec is being executed with root privileges.Without the setuid or setgid bits on root the gLExec executable is like any other regular executable.

The safety features of gLExec are implemented with great care to avoid misuse. Note that a user runningglexec does NOT gain root access at any time. root permissions are ONLY used to perform the actualuserswitch from the original to the final Unix account. All intermediate actions, including all I/O, areexplicitly done with the privileges of an ordinary user.

Safety features

A couple of safety features that are build in the gLExec tool are:

The LD_LIBRARY_PATH, LD_RUN_PATH and other LD_* environment variables are removedfrom the process environment by the Operating System before the first line of gLExec code isexecuted by a Unix and Linux system. Only the /etc/ld.so.conf{.d/}, RPATH settings and othersystem specific paths are used and resolved. This statement holds for any setuid or setgid executable.

•

The rest of the environment is stripped off by gLExec, since there are a couple of environmentsettings that could easily lead to a root exploit in the standard library of a Unix and Linux system.Therefore, by default only the GLEXEC_* environment variables are kept. There is an option in theglexec.conf file to preserve more variables, but these must be selected with great care and setup byeach System Administrator on all their machines. These can not be influenced by the user. Startingfrom gLExec 0.7, all variables starting with MALLOC_ cannot be whitelisted.

•

If the target user is authorized and when a mapping and Unix process identity switch the HOME andX509_USER_PROXY will be rewritten. Their value will contain the paths that are relevant for thetarget user account. Note that there are some bugs related to this in versions before 0.7 which meanthese variables are sometimes set to incorrect values. These are not classified as vulnerabilities, butcould lead to failure. From version 0.7 onwards, this has been resolved.

•


Need to Know's 19

The target user process has the Unix identity as mapped by LCMAPS and configured by the localsystem administrator.

•

How to work with the gLExec secured environment

To cope with the environment clean-up we've developed gLExec wrapper scripts which are capable ofteleporting your environment variables. These are designed to take care of your environment variables andcooperate with gLExec in the best possible way. This makes it virtually transparent to the Pilot Job frameworkor other middleware that wishes to propagate environment settings through gLExec.

More information about these wrapper scripts can be found on the gLExec Environment Wrap and Unwrapscripts page.

More information

More information can be found on the FAQs and misconceptions about gLExec page.


Safety features 20

FAQs and misconceptions about gLExecHere is a list of common question and misconceptions regarding gLExec.

Contents

1 Comparisons• 2 Infrastructure• 3 Privileges and PrivilegeSeparation

•

4 Motivations•

Comparisons

Question : Is gLExec similar to sudo?

Answer : No. Sudo is generically meant to execute a program or script with root-privileges. gLExec will notperform any task besides the actual user switch with root-privileges. All operational tasks within gLExec areperformed with the privileges of either the calling (system/Unix) user (e.g. reading the proxy), the glexecuser/group (e.g. reading the config file) or the mapped user (writing the proxy and executing the command).

Question : Is gLExec like Apache's suexec?

Answer : No. gLExec does implement all the safety checks of suexec, but suexec lacks the advanced Gridcredential authentication, authorization and account mapping features that we've build-in. For example:gLExec's uses LCAS as a pluggable authorization framework and it uses LCMAPS as pluggable framework toperform the local account mapping. The LCMAPS layer can also be extended to use SCAS, Argus or GUMS.gLExec can also be restricted for a limited list of accounts from a whitelist.

Infrastructure

Question : Is my Batch System able to handle identity switching during a job run?

Answer : Processes like the pbs_mom run with root-privileges and thus have all the privileges to manage alljob types. Please have a look at the Batch System Interoperability experiences with different types of BatchSystems and a non-gLExec testing tool.

Question : Who controls the gLExec run mode i.e. choice to run in logging-only mode or setuid mode?

Answer : The site is in full control of this choice. The system administrator will need to install the rightconfiguration settings for the mapping process to function properly and will need to install gLExec with therequired setuid-bit enable on the binary with the root owenership.


FAQs and misconceptions about gLExec 21

Question : gLExec runs with elevated privileges, isn't it dangerous to offer gLExec on my Worker Nodes?

Answer : Security measures build from the ground up prevent any use of the elevated privileges. Both theuser process calling gLExec and the executed command with the target identity are unable to use gLExec'sprivileges. Multiple build-in security measures prevent a target user to be mapped to a root account or rootgroup.

Question : Isn't gLExec a risk to my infrastructure?

Answer : Taking the use case of Multi User Pilot Job Frameworks as an example; the Pilot Job frameworkshave moved the front door of your site from the CE to the WN. gLExec on the Worker Nodes gives backcontrol to the Sites which they have on their CEs and regular jobs. With the identity switching feature enabledit can give the VOs the opportunity to not be regarded as one user i.e. when one user in the VO goes rogue theentire VO is suspected and might be disallowed as a whole from a site.

Privileges and Privilege Separation

Question : Can every user on my system call gLExec?

Answer : It is completely up to you. gLExec allows you to whitelist users, but you can disable thisrestriction.

We offer a few options from within gLExec:

Per account white listing: In the glexec.conf file write user_white_list = okoeroo1. Per pool of account white listing: In the glexec.conf file write user_white_list = .atlpilot2. By letting the calling account be a member of the special Unix group 'glexec'.3. You could whitelist every account by using the wildcard *. There are good motivations why you wantto do this and it should not blindly be regarded as a security risk. Please read ahead in the motivationsection for details about this.

4.

Note: Even the 'root' account itself needs to be whitelisted to be able to work with gLExec. For moreinformation see the glexec and glexec.conf man pages for the user_white_list option.

Question : If a user is able to use gLExec can I now just execute a command?

Answer : After being authorized, Yes. Based on the presented credentials gLExec will use LCAS locally foran authorization decision, followed by LCMAPS which is able to call remote services like SCAS, GUMS orArgus for an authorization decision.


Infrastructure 22

Motivations

We've invited multiple vulnerability assessment teams to look at gLExec. They've assessed the code in a lot ofdetail and written multiple reports about the quality of the code and the vulnerabilities that were in them. Theoverall conclusions were that we've done a very good job over time in creating a very secure tool that exactlydoes what we advertise. We've build upon our experiences in the LCG-CE, gridFTPd and other securityrelated tools that we've made over time. We have a strong drive to make gLExec even safer than it already iswithout compromising the usability of the tool.


Motivations 23

Building gLExec and its gLite dependencies fromSVN source

Contents

1 Introduction• 2 Prerequisites: Globus and globalsettings

2.1 Binary Globusinstallation

♦

2.2 Globus installationfrom source

2.2.1 GlobusToolkit 5

◊

♦

•

3 VOMS API• 4 LCMAPS• 5 LCAS• 6 LCAS interface• 7 gLExec• 8 LCMAPS plugins basic• 9 LCMAPS plugins verify-proxy• 10 LCMAPS plugins voms• 11 LCMAPS plugins afs• 12 LCMAPS plugins GUMS• 13 PEP-C Library• 14 LCMAPS plugins C-pep• 15 SAML2-XACML2 Library• 16 LCMAPS plugins SCAS client• 17 SCAS• 18 LCAS plugins basic• 19 LCAS plugins check-executable• 20 GridSite Core• 21 LCAS plugins voms• 22 LCAS LCMAPS GT4 interface•

Introduction

This page explains the steps needed to build gLite tools, in particular gLExec and its LCMAPS and LCASdependencies directly from the source in CVS. Note that the order in which these packages are describedbelow ensures that all the dependencies are resolved.

We also provide an example script which builds all the different tools consecutively and which have beenused as the source for this wiki page. Typical usage:


Building gLExec and its gLite dependencies from SVN source 24

./sac_from_source.sh \ -c emi1rc.config \ -F prefix=/usr,libdir=/usr/lib64,sysconfdir=/etc \ -o stdout.txt -e stderr.txt \ lcmaps_interface glexec

This would download lcmaps-interface and glexec into /tmp/source, build them and install them using amake DESTDIR=/tmp/build install sequence.

If one wants to change the configure lines, the easiest is to go to /tmp/source/glexec and do areconfigure with the right options, or change the -F options above. There are quite a few of them possible, forexample, the location where components look for lcmaps can be specified usinglcmaps-prefix=<directory>

Upon completion, two files are created (by default in the source dir):

failedcomps.txt - containing a list of components that failed building• configflag.txt - containing the used flags. This can be used as input instead of the -F byspecifying -f<file>

•

Use ./sac_from_source.sh -h for help

Note that this is work in progress, hence comments, suggestions etc. are highly appreciated.

Prerequisites: Globus and global settings

First define the build and runtime installation paths:

export source=/tmp/source # Where to download sourcesexport globus=/tmp/build/globus # Where to install/find globusexport gridsite=/tmp/build/gridsite # Where to install/find gridsiteexport glite=/tmp/build/glite # Where to find glite buildsexport prefix=${glite} # Where to install glite builds

Make sure ${source} exists. Set the correct CVSROOT for gLite downloads:

export CVSROOT=:pserver:[email protected]:/cvs/glite # anonymous CVS root

Note that instead of using the anonymous CVS checkout commands below

cvs co -r TAG COMPONENT

one can also download and untar a tarball from

wget -nv -O - http://glite.cvs.cern.ch/cgi-bin/glite.cgi/COMPONENT.tar.gz\?view=tar\&pathrev=TAG | tar -zxvf -


Introduction 25

or, for the default HEAD tag:

wget -nv -O - http://glite.cvs.cern.ch/cgi-bin/glite.cgi/COMPONENT.tar.gz\?view=tar | tar -zxvf -

In that case the CVSROOT does not need to be set.

There are currently two ways to get a working globus library.

Binary Globus installation

For the following OSes it can be found in the Etics repositories:

RedHat-4 32 bits (also for SL(C)-4 and Centos-4): globus-4.0.3-VDT-1.6.1-7.tar.gz• RedHat5 64 bits (also for SL(C)-5 and Centos-5): globus-4.0.7-VDT-1.10.1-1.tar.gz• OpenSUSE 11 64 bits: globus-4.0.7-VDT-1.10.1-1.tar.gz• Debian-5 64 bits: globus-4.0.8-VDT-2.0.0-2.tar.gz•

Since all these tarballs assume installation in /opt/globus unpack and 'relocate' as follows:

mkdir -p ${globus} && \cd ${globus} && \tar -zxf <globus tarball> && \find -type f -name \*.la|while read file;do sed s+/opt/globus+${globus}+g ${file} > ${file}.new && \ mv -f ${file}.new ${file}done

Set one of the following exports, depending on 32 or 64 bit platform:

export globus_flav=gcc32dbg or export globus_flav=gcc64dbg

Globus installation from source

Download the gt4.0.8-all-source-installer.tar.bz2 source tarball, unpack and go to the createdgt4.0.8-all-source-installer directory.

./configure --prefix=${globus} \ --disable-gridftp --disable-gsiopenssh --disable-myproxy \ --disable-rls --disable-drs --disable-rendezvous --disable-tests \ --disable-prewsgram --disable-wsgram --disable-wsjava --disable-wsc \ --disable-wsmds --disable-wsdel --disable-wsrft --disable-wscas \ --disable-wstests --disable-webmdsmake globus-gsimake install

In case you want to build the LCAS LCMAPS GT4 interface, you will also need to add the build targetsglobus_gridmap_callout_error and globus_authz

make globus-gsi globus_gridmap_callout_error globus_authz


Prerequisites: Globus and global settings 26

make install

Now set the correct globus flavour, e.g.:

export globus_flav=unsetif [ -f "${globus}/etc/globus_core/flavor_gcc64dbg.gpt" ];then globus_flav=gcc64dbgelif [ -f "${globus}/etc/globus_core/flavor_gcc64.gpt" ];then globus_flav=gcc64elif [ -f "${globus}/etc/globus_core/flavor_gcc32dbg.gpt" ];then globus_flav=gcc32dbgelif [ -f "${globus}/etc/globus_core/flavor_gcc32.gpt" ];then globus_flav=gcc32fi

Globus Toolkit 5

Although not certified, pre-certification shows gLExec works with GT5.

In order to build using GT5, download the source gt5.0.1-all-source-installer.tar.bz2 and build the same wayas for GT4 above.

VOMS API

Dependencies: Globus

cd ${source}cvs co -r glite-security-voms_R_1_9_16_2 org.glite.security.vomscd org.glite.security.voms./configure --prefix=${prefix} --with-globus-prefix=${globus} --disable-java --with-api-onlymake && make install

LCMAPS

Dependencies: Globus, VOMS API

Also note that we use the same value for both globus*flavor options. This is only relevant when buildingglobus from source, since we only (need to) build the non-threading globus library. However, the voms test,defined in the glite_security.m4 macros, uses an include path based on the threaded globus library.

cd ${source}cvs co org.glite.build.common-cppcvs co org.glite.security.lcmapscd org.glite.security.lcmapscp -p ../org.glite.build.common-cpp/m4/{globus,glite,glite_security,lcmaps}.m4 ./project./bootstrap./configure --prefix=${prefix} \ --with-glite-location=${glite} \ --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav} --with-globus-nothr-flavor=${globus_flav}


Globus installation from source 27

make && make install

LCAS

Dependencies: Globus

Note: glite-build-common-cpp is also checked out under LCMAPS.

cd ${source}cvs co org.glite.build.common-cppcvs co org.glite.security.lcascd org.glite.security.lcascp -p ../org.glite.build.common-cpp/m4/{glite,globus,lcmaps}.m4 ./project./bootstrap && \./configure --prefix=${prefix} \ --with-glite-location=${glite} \ --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

LCAS interface

cd ${source}cvs co org.glite.security.lcas-interfacecd org.glite.security.lcas-interfacecp -p ../org.glite.build.common-cpp/m4/glite.m4 ./project./bootstrap./configure --prefix=${prefix}make install

gLExec

Dependencies: Globus, LCMAPS, LCAS, LCAS interface

Note: for Debian-5 set the following extra export:

export LDFLAGS="-Wl,-rpath -Wl,${globus}/lib"

Note: the HEAD version of gLExec has a new configure option --with-glexec-conf to allow settingthe fixed location of the configuration file, which defaults to /opt/glite/etc/glexec.conf. In olderversions (including production), it is possible to do this by setting the following export before callingconfigure. Note the particular combination of single quotes and escaped double quotes:

export CPPFLAGS=-DGLEXEC_CONFIG_FILE='\"'${prefix}/etc/myglexec.conf'\"'

cd ${source}cvs co org.glite.security.glexeccd org.glite.security.glexeccp -p ../org.glite.build.common-cpp/m4/{glite,globus,lcmaps}.m4 ./project


LCMAPS 28

./bootstrap

./configure --prefix=${prefix} \ --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

LCMAPS plugins basic

Dependencies: Globus, LCMAPS

cd ${source}cvs co org.glite.security.lcmaps-plugins-basiccd org.glite.security.lcmaps-plugins-basiccp -p ../org.glite.build.common-cpp/m4/{glite,globus,lcmaps,gridlist}.m4 ./project./bootstrap./configure --prefix=${prefix} --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

LCMAPS plugins verify-proxy

Dependencies: LCMAPS

cd ${source}cvs co org.glite.security.lcmaps-plugins-verify-proxycd org.glite.security.lcmaps-plugins-verify-proxycp -p ../org.glite.build.common-cpp/m4/{glite,glite_security}.m4 ./project./bootstrap./configure --prefix=${prefix} --with-glite-location=${glite}make && make install

LCMAPS plugins voms

Dependencies: Globus, VOMS API, LCMAPS

cd ${source}cvs co org.glite.security.lcmaps-plugins-vomscd org.glite.security.lcmaps-plugins-vomscp -p ../org.glite.build.common-cpp/m4/{glite,glite_security,globus,lcmaps,gridlist}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install


gLExec 29

LCMAPS plugins afs


cd ${source}cvs co org.glite.security.lcmaps-plugins-afscd org.glite.security.lcmaps-plugins-afscp -p ../org.glite.build.common-cpp/m4/{glite,globus}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

LCMAPS plugins GUMS


cd ${source}cvs co org.glite.security.lcmaps-plugins-gumscd org.glite.security.lcmaps-plugins-gumscp -p ../org.glite.build.common-cpp/m4/{glite,glite_security,globus}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

PEP-C Library

Note: the way the PEP-C library determines the library path is not fully compatible with the way LCMAPSdoes it. To fix this, define:

export pepclibdir=${glite}/<libdir used by LCMAPS>

cd ${source}svn co http://svnweb.cern.ch/guest/glxa/pep-c-lib/tags/1_3_0 org.glite.authz.pep-ccd org.glite.authz.pep-c./autotools.sh./configure --prefix=${glite} --libdir=${pepclibdir}make && make html && make install

LCMAPS plugins C-pep

Dependencies: LCMAPS, PEP-C Library

cd ${source}cvs co org.glite.security.lcmaps-plugins-c-pep


LCMAPS plugins afs 30

cd org.glite.security.lcmaps-plugins-c-pepcp -p ../org.glite.build.common-cpp/m4/{glite,glite_security}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite}make && make install

SAML2-XACML2 Library

Note: glite-build-common-cpp is also checked out under LCMAPS and/or LCAS

cd ${source} cvs co -r glite-build-common-cpp_R_3_2_7_1 org.glite.build.common-cppcvs co org.glite.security.saml2-xacml2-c-libcd org.glite.security.saml2-xacml2-c-libcp -v -p ../org.glite.build.common-cpp/m4/glite.m4 ./projectexport CXXFLAGS=-fPIC cd gsoap-2.7../autogen.sh./configure --prefix=${glite}make && make installcd ../xacml-1.0../autogen.sh./configure --prefix=${glite} --with-gsoap=${glite}make && make install

LCMAPS plugins SCAS client

Dependencies: LCMAPS, SAML2-XACML2 Library

cd ${source}cvs co org.glite.security.lcmaps-plugins-scas-clientcd org.glite.security.lcmaps-plugins-scas-clientcp -p ../org.glite.build.common-cpp/m4/{glite,glite_security,lcmaps}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite}make && make install

SCAS


cd ${source}cvs co org.glite.security.scascd org.glite.security.scascp -p ../org.glite.build.common-cpp/m4/{globus,glite,glite_security,lcmaps}.m4 ./project./bootstrap./configure --prefix=${prefix} \ --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install


LCMAPS plugins C-pep 31

LCAS plugins basic

Dependencies: Globus, LCAS

cd ${source}cvs co org.glite.security.lcas-plugins-basiccd org.glite.security.lcas-plugins-basiccp -p ../org.glite.build.common-cpp/m4/{glite,globus,gridlist}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

LCAS plugins check-executable

Dependencies: Globus, LCAS

cd ${source}cvs co org.glite.security.lcas-plugins-check-executablecd org.glite.security.lcas-plugins-check-executablecp -p ../org.glite.build.common-cpp/m4/{glite,globus,gridlist}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install

GridSite Core

Dependencies: global settings

Note: GridSite Core needs to know the library path (lib or lib64), therefore

export gridsitelibdir=<libdir used by LCAS>

cd ${source}cvs co org.gridsite.corecd org.gridsite.core/srcmake prefix=${gridsite} libdir=${gridsitelibdir}make prefix=${gridsite} install

LCAS plugins voms

Dependencies: Globus, VOMS, LCAS, GridSite Core

cd ${source}cvs co org.glite.security.lcas-plugins-voms


LCAS plugins basic 32

cd org.glite.security.lcas-plugins-vomscp -p ../org.glite.build.common-cpp/m4/{glite,glite_security,globus,gridsite,gridlist}.m4 ./project./bootstrap./configure --prefix=${glite} --with-glite-location=${glite} \ --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav} --with-gridsite-prefix=${gridsite} --with-gridsite-ssl=systemmake && make install

LCAS LCMAPS GT4 interface


Note: only this component needs the extra build targets globus_gridmap_callout_error globus_authz forbuilding globus from source.

cd ${source}cvs co org.glite.security.lcas-lcmaps-gt4-interfacecd org.glite.security.lcas-lcmaps-gt4-interfacecp -p ../org.glite.build.common-cpp/m4/{globus,glite,lcmaps}.m4 ./project./bootstrap./configure --prefix=${prefix} \ --with-glite-location=${glite} --with-globus-prefix=${globus} --with-globus-thr-flavor=${globus_flav}pthr --with-globus-nothr-flavor=${globus_flav}make && make install


LCAS plugins voms 33

Building gLExec from src rpm

How to build gLExec from a .src.rpm

This wiki used to describe instructions for the gLite era RPMs, the old page can be found here.

See also Building gLExec and its gLite dependencies from SVN source for details on how to build directlyfrom source.

The now advised method of rebuilding gLExec from source RPM is using the Nikhef RPMs:

You can use the following shell script, which can be downloaded here• Adapt the variables at the top to point to right directories• Run it in a temporary directory as ordinary user.• The resulting binary RPM will be found in the RPMS/*/ subdirectory.•

#!/bin/sh

# SET CUSTOM BUILD ARGUMENTS HERE

# gLite-3.2 and EMI-1lcmaps_moddir_sfx=/modules # LCMAPS moduledir is ${libdir}${lcmaps_moddir_sfx}lcas_moddir_sfx=/modules # LCAS moduledir is ${libdir}${lcas_moddir_sfx}

# EMI-2 and EPEL#lcmaps_moddir_sfx=/lcmaps # LCMAPS moduledir is ${libdir}${lcmaps_moddir_sfx}#lcas_moddir_sfx=/lcas # LCAS moduledir is ${libdir}${lcas_moddir_sfx}

# gLite-3.2 directoriesglexec_pfx=/opt/gliteglexec_etc=/opt/glite/etcglexec_doc=/opt/glite/share/doc

# EMI and EPEL directories#glexec_pfx=/usr#glexec_etc=/etc#glexec_doc=/usr/share/doc

lcmaps_version=1.4.30-1glexec_version=0.8.11-2

# END OF BUILD ARGUMENTS

# Setup build infrastructureexport TOPDIR=`pwd`mkdir -p $TOPDIR/{SRPMS,SOURCES,SPECS,BUILD,RPMS/x86_64,RPMS/i386}

# Download and install lcmaps-interface and glexec srcrpm2cpio http://software.nikhef.nl/dist/redhat/el5/mwsec/x86_64/lcmaps-interface-${lcmaps_version}.x86_64.rpm | cpio -idrpm --define "_topdir $TOPDIR" -i http://software.nikhef.nl/dist/redhat/el5/mwsec/SRPMS/glexec-${glexec_version}.src.rpm


Building gLExec from src rpm 34

# Patch spec file to match module directories for LCAS and LCMAPSsed -i "s+^$%configure$.*+\1 --with-lcmaps-moduledir-sfx=$lcmaps_moddir_sfx --with-lcas-moduledir-sfx=$lcas_moddir_sfx+" $TOPDIR/SPECS/glexec.spec

# Build the RPMCFLAGS=-I$TOPDIR/usr/include rpmbuild \ --nodeps \ -ba --define "_topdir $TOPDIR" \ --define "_prefix $glexec_pfx" \ --define "_sysconfdir $glexec_etc" \ --define "_defaultdocdir $glexec_doc" \ $TOPDIR/SPECS/glexec.spec


How to build gLExec from a .src.rpm 35

Table of Contents Argus: gLExec with Argus: Description..........................................................................................................1

Module Description............................................................................................................................................2

Authorization and Mapping..............................................................................................................................3 XACML Request....................................................................................................................................3 XACML Response..................................................................................................................................3

Installation..........................................................................................................................................................4

i

Argus: gLExec with Argus: Description

Argus: gLExec with Argus: Description 1

Module DescriptiongLExec is a program to make the required mapping between the grid world and the Unix notion of users andgroups, and has the capacity to enforce that mapping by modifying the uid and gids of running processes.Based on LCAS and LCMAPS, it can both act as a light-weight 'gatekeeper' replacement, and even be used onthe worker node in late-binding (pilot job) scenarios.

The gLExec uses the LCMAPS framework to abstract different implementations and techniques that can beimplemented through the use of specialized plug-ins. The plug-ins do the actual work (e.g. extensivecredentials, procuring an account locally or through a central authorization service, like Argus).

The gLExec will interact with Argus using an LCMAPS plug-in which uses the PEP-C library tocommunicate to it. The plug-in calls out to the Argus PEP Daemon. The response from the Argus PEPDaemon is extracted and used to deny or fulfill the mapping request to the resource.

More information about gLExec can be found on the Nikhef GridWiki for gLExec page which includesspecific information about batch-system handling, with example scripts, the gLExec wrapper scripts and othergLExec related information.

Focused towards system administrators, there is also a Service Reference Card made available for gLExec.

Module Description 2

Authorization and MappingBased on the Grid credentials, LCMAPS C PEP plug-in will send an XACML request to the Argus PEPDaemon, and then parse the XACML response decision to authorize the user and the obligations to map himto a local account which will effectively switch the active Unix account of the running process.

XACML Request

The gLExec LCMAPS PEP plug-in sends an XACML request to the PEP Daemon with the followingelements by default*:

XACML subject with the attribute element:AttributeId: urn:oasis:names:tc:xacml:1.0:subject:key-info♦ Value: The PEM encoded Grid credentials provided by the calling process, fetched from thefile content located by the environment variable $GLEXEC_USER_CERT. The location tothe proxy file of the pilot job payload owner (e.g. the end user) must be set by this variable inorder for gLExec to pass it on. The mapping will be based on this information.

♦

•

XACML resource with the attribute element:AttributeId: urn:oasis:names:tc:xacml:1.0:resource:resource-id♦ Value: The type of resource of the node and service from where the request originated (e.g.SE, CE, WN or RB/WMS).

♦

•

XACML action with the attribute element:AttributeId: urn:oasis:names:tc:xacml:1.0:action:action-id♦ Value: The type of action to be taken on the node from where the request originated (e.g.access-file, queue, execute-now).

♦

•

XACML environment with the attribute element:AttributeId: urn:oasis:names:tc:xacml:1.0:subject:key-info♦ Value: The PEM encoded Grid credentials provided by the calling process, fetched from thefile content located by the environment variable $X509_USER_PROXY. The location to theproxy file of the pilot job executor or pilot job framework manager must be set by thisvariable in case of a pilot job framework scenario.

♦

•

XACML Response

The PEP Daemon sends back a XACML response to the gLExec LCMAPS PEP plug-in. The followingXACML response elements are parsed to authorize and map the user:

XACML decision element: Contains the authorization decision Permit, Deny, Indeterminateor NotApplicable

•

XACML obligation, ObligationId:http://glite.org/xacml/obligation/local-environment-map/posix, with thethree possible attribute assignment elements:

AttributeId: http://glite.org/xacml/attribute/user-id♦ Value: Contains the Unix User ID of the mapped user account in a string format.♦ AttributeId: http://glite.org/xacml/attribute/group-id/primary♦ Value: Contains the Unix Group ID of the mapped primary group in a string format.♦ AttributeId: http://glite.org/xacml/attribute/group-id♦ Value: Contains the Unix Secondary Group ID of the mapped group in a string format.♦

•

The local identity mapping will only succeed if the authorization decision is Permit.

*: The previously used XACML attribute profile can still be selected, but this needs to be explicitlyconfigured.

Authorization and Mapping 3

InstallationPlease move to the gLExec with LCMAPS C PEP Plug-in installation guide.

This topic: EGEE > AuthZPEPgLExecInfoTopic revision: r7 - 12-Apr-2010 - OscarKoeroo

Copyright &© by the contributing authors. All material on this collaboration platform is theproperty of the contributing authors.Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback

Installation 4

Table of Contents Testing glexec on the worker node using YAIM.............................................................................................1

i

Testing glexec on the worker node using YAIMThe text below is outdated and needs to be revised. In the meantime, a test suit for the YAIM functions isbeing developed. (See the attachment.) The full suit can be run (as root) with Dejagnu. It contains a limited setof tests but adding more tests is now rather simple. All tests can be run standalone even without Dejagnu.

Be aware that these test do not fully cover the functionality of the YAIM scripts for GLEXEC_wn. Manualtesting of the validity of the resulting configuration is necessary.

The glexec on the worker node scenario is meant especially for pilot job frameworks; the user identityswitching powers of glexec are called on to change the pilot user to the real user, as soon as the job hasfetched the real user's payload and the real user's proxy.

In spite of this already particularly specific scenario, there are six different deployment cases that need to betested, selected by three main choices:

whether or not to use SCAS instead of a local LCAS/LCMAPS configuration1. whether or not to install glexec with setuid mode (the other mode is called logging-only)2. whether to log to syslog or to specific logfiles (logging only must use syslog)3.

The following snippet can be used in your site-info.def to fiddle with these choices.

# glexec related variables

# Define this variable to configure the glexec to work against a SCAS server.# - yes : means you want to use a SCAS server and therefore you need to define:# - SCAS_HOST="scas server hostname"# - SCAS_PORT="scas server port"# - no : means you don't want to use any SCAS server.#GLEXEC_WN_SCAS_ENABLED="yes or no"GLEXEC_WN_SCAS_ENABLED="no"#GLEXEC_WN_SCAS_ENABLED="yes"

SCAS_HOST=YOUR_SCAS_SERVER_FQDNSCAS_PORT=8443

# Define this variable to configure the operation mode of glexec in your WN.# The possibilities are:# - setuid : it will actually enable glexec to do the identity change# - log-only : it won't do any identity change. If you select log-only, it# doesn't matter whether SCAS is enabled or not. It isn't used.#GLEXEC_WN_OPMODE="setuid or log-only" #GLEXEC_WN_OPMODE="log-only" GLEXEC_WN_OPMODE="setuid"

# Optional variable to tell glexec where to send the glexec logging information.# There are two values: 'syslog' and 'file'. The default is 'syslog'# The value 'syslog' puts all messages in the syslog# and 'file' puts the messages in a file.# Define this variable if you want to specify a file.# For value 'file' define GLEXEC_WN_LOG_FILE as well.# REMEMBER that for log-only mode, 'syslog' should be used !GLEXEC_WN_LOG_DESTINATION=fileGLEXEC_WN_LOG_FILE=/var/log/glexec/glexec_log#GLEXEC_WN_LOG_DESTINATION=syslogGLEXEC_EXTRA_WHITELIST="comma_separated_list_of_test_users"

To test glexec, configure it with YAIM. After making the desired settings with the above variables, run YAIMlike this:

Testing glexec on the worker node using YAIM 1

/opt/glite/yaim/bin/yaim -c -s site-info.def -n WN -n glite-GLEXEC_wn

Then log in to the machine as one of the whitelisted users. Install a valid proxy in and point to it:

export GLEXEC_CLIENT_CERT=your-proxy-file

Then run a simple test:

/opt/glite/sbin/glexec /usr/bin/id

This should return the output of the id command with the identity of the user you've been mapped to, but verylikely you've made a mistake and the message is simply:

glexec was unable to execute the request. See glexec log for moredetails.

Follow that advice! If you set logging to file, inspect the logfiles for both glexec and lcas-lcmaps. If you setlogging to syslog only, check /var/log/messages. You may increase the verbosity by setting a higher value forthe log_level, lcmaps_log_level and lcas_log_level in/opt/glite/etc/glexec.conf.

-- DennisVanDok - 19 Jan 2009

testsuite.tar.gz: testsuite for GLEXEC_wn YAIM functions•

This topic: EGEE > YAIM_glexec_wnTopic revision: r3 - 17-Nov-2009 - DennisVanDok

Copyright &© by the contributing authors. All material on this collaboration platform is theproperty of the contributing authors.Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback

YAIM_glexec_wn < EGEE < TWiki

Testing glexec on the worker node using YAIM 2

Table of Contents Deployment of gLExec on the Worker Node...................................................................................................1

Applicability...........................................................................................................................................1 Background.............................................................................................................................................1 Time lines...............................................................................................................................................1 How to implement gLExec on the WN...................................................................................................2 Monitoring of gLExec tests....................................................................................................................3 More information....................................................................................................................................4

i

Deployment of gLExec on the Worker Node

Applicability

The information on this page is relevant for WLCG sites with CREAM, LCG-CE or OSG-CE services (theARC-CE is not concerned). Installation and configuration advice is given for gLite/EMI middleware.USATLAS and USCMS sites are asked to coordinate with their respective T1 sites instead. Sites that onlysupport ALICE are not concerned for the time being. It is understood that for various reasons some sites maybe unable to comply with the guidelines detailed below; the affected sites may need to be excluded from useby Multi User Pilot Jobs in the future.

Background

Each of the experiments has a framework that supports the submission of so-called pilot jobs:

ALICE - AliEn• ATLAS - PanDA• CMS - GlideinWMS• LHCb - DIRAC•

On the Worker Node (WN) a pilot job deploys a pilot agent that contacts the task queue managed by the VO'sframework, to obtain the highest-priority task (a.k.a. payload) that is compatible with the WN environment.

A pilot job can either be "single-user" (a.k.a. "private"), i.e. run only payloads submitted with the samecredentials as its own, or "multi-user", in which case it may run payloads submitted by any user authorized bythe VO.

Multi-user pilot jobs (MUPJs) can only be submitted by a small group of people in each experiment,essentially production managers, using a specific VOMS role (Role=pilot).

When a payload has finished and the pilot job slot has sufficient CPU and wallclock time left, another taskmight be downloaded, possibly submitted by a different user, etc.

Various sites were uncomfortable with the idea that the users who submitted such tasks would not beidentifiable by the site in case forensic investigations are needed after an incident.

This led to the idea of introducing a mechanism allowing sites to exercise authorization and obtain traceabilitywithin MUPJs. The proposed implementation depends on a command that allows the pilot job to imitate theCE to a certain extent.

That command is "glexec" and is similar to Apache's "suexec". Glexec has two running modes. In the"log-only" mode it logs the authorization decision and runs a given payload under the identity of the invokingpilot agent. In the "identity-changing" mode it logs the authorization decision, maps the payload proxy andruns the payload under the corresponding account. In the latter case glexec needs to be setuid root.

More details at: https://wlcg-tf.hep.ac.uk/wiki/Multi_User_Pilot_Jobs

Time lines

During the WLCG Management Board meeting of Feb 8 2011 it was decided that CERN and the T1 sitesshould have gLExec on the WN working by the end of March 2011, while for T2 sites the aim was the end ofJune 2011.

Deployment of gLExec on the Worker Node 1

Subsequent discussions then led to a suspension of the deployment until the matter of Multi User Pilot Jobshad been revisited in the WLCG Technical Evolution Groups on Security and Workload Management. Theoutcome is that currently the use of gLExec is the only viable method for user separation in Multi User PilotJobs and that its deployment should hence continue.

Each of the experiments either can use it already or has plans for integrating it:

ALICE - new adaptations of AliEn under study.• ATLAS - transparent usage planned through GlideinWMS back-end of PanDA.• CMS - transparent usage available through GlideinWMS.• LHCb - usage configurable in DIRAC.•

Further details at:

TEG Reports meeting•

WN security status report•

How to implement gLExec on the WN

This section pertains to gLite/EMI middleware. USATLAS and USCMS sites should consult with theirrespective T1 sites.

Each CE supporting the use of glexec on the WN must publish an extra GlueCECapability "glexec".See the "CE_CAPABILITY" description in this YAIM documentation:https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#site_info_def

•

On the CE the pilot role needs to be configured for each supported experiment and for the "ops" VO.The roles should be mapped to separate sets of accounts that will be put into the gLExec "whitelist"(accounts that are allowed to run the "glexec" command). Examples are shown here:https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#Notes_on_using_SCAS_and_ARGUS

•

An Argus server should be set up (SCAS is deprecated):http://glite.cern.ch/glite-ARGUS/♦ https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#ARGUS♦ Note: the Argus server usually needs to share the "gridmapdir" with the CEs to guarantee thata particular proxy will always be mapped to the same account. Beware that the Argus serverneeds to have write access to that directory. An alternative would be for Argus and the CEs touse non-overlapping sets of accounts. The next version of CREAM (1.7, to be released as partof EMI-1) should support the use of Argus also on the CE level, but any remaining LCG-CEwould still require a shared gridmapdir or its own set of accounts.

♦

Note: the current version of Argus does not update the time stamps of the pool account filesin the gridmapdir:https://savannah.cern.ch/bugs/index.php?83281This may cause the lcg-expiregridmapdir cron job to remove mappings that wererecently added. For the time being this is not a real problem when Argus is used to supportgLExec on the WN only (i.e. no CE depends on Argus).

♦

Note: the Argus server must be configured to accept ALL groups and roles that are allowed torun jobs at your site!Example "groups.conf" for some WLCG VO:

"/vo/ROLE=lcgadmin":::sgm: "/vo/ROLE=production":::prd: "/vo/ROLE=pilot":::pilot: "/vo/*"::::

♦

•

GlexecDeployment < LCG < TWiki

Time lines 2

"/vo"::::

YAIM does not (yet) configure the corresponding policies in the PAP, but a reasonablepolicy can easily be derived from the groupmapfile by running a script created byAntonio Delgado of CIEMAT:http://wwwae.ciemat.es/~delgadop/from-groupmap-to-policy.shThe output can be saved in a file that can be fed to the PAP as follows:

sh from-groupmap-to-policy.sh > my-policy.spl pap-admin add-policies-from-file my-policy.spl

Note: in principle the number of explicitly recognized groups and roles can be reducedcompared to the configuration of the CE (that is one of the benefits of using pilot jobs), butfor the time being sites are recommended to imitate the CE configuration on the Argusserver: it is easy and would avoid confusion.

♦

Note: it is understood that a glexec payload task would not be able to install software on sitesthat have the shared area on AFS (because glexec currently will not provide the payload withan AFS token).

♦

Note: the current version of Argus does not yet support host certificates that have"CN=host/" in the DN (obsolete syntax):https://savannah.cern.ch/bugs/?82193

♦

Note: random glexec timeout errors have been observed in a correct setup:https://savannah.cern.ch/bugs/?82681

♦

On the WN the "glite-GLEXEC-wn" meta package should be installed and configured (preferably in"setuid" mode) according to the YAIM documentation:

http://glite.cern.ch/glite-GLEXEC_wn/♦ https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#GLEXEC_wn♦ Note: the current glexec version in gLite 3.2 fails with an error "problem with thelocal SSL certificate" if the pilot or target proxy is located on a shared homedirectory exported with the root_squash option; this is fixed in EMI-1; tickets:https://ggus.eu/tech/ticket_show.php?ticket=69332https://ggus.eu/ws/ticket_info.php?ticket=71403

♦

Note: the "glite-GLEXEC-wn" is largely independent of the "glite-WN" package. The"glexec" executable is expected to be located in the directory $GLEXEC_LOCATION/sbinif that variable is defined, else in the directory $GLITE_LOCATION/sbin. A future versionof YAIM will ensure that GLEXEC_LOCATION is always defined.

♦

Note: there is no relocatable version of the "glite-GLEXEC-wn" meta package yet. To deploya relocatable version the admin would have to build "glexec" from its source, because thepath to the "glexec" configuration file needs to be hardcoded in the executable for securityreasons. The current path is /opt/glite/etc/glexec.conf, but for "glexec" in theEMI-1 release it will be /etc/glexec.conf, which reinforces the idea that "glexec" ismore a system package than an ordinary middleware component. This may reduce the needfor a relocatable version. For the time being, a recipe for building "glexec" and itsdependencies from CVS sources is given here:

https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Building_gLExec_and_its_gLite_dependencies_from_CVS_source◊

♦

•

Monitoring of gLExec tests

For LCG-CE and CREAM services registered in the GOCDB (EGI and direct partners) the "ops" VO cansubmit hourly test jobs with "/ops/Role=pilot" as the primary attribute in the proxy and executing a simple testof the "glexec" command on the WN, using its own proxy as the "payload" proxy: no identity change shalloccur, but all other aspects of the setup are thus tested. The tests used to be submitted centrally, but thatfunctionality has been decommissioned early April 2012, see the notes below.


How to implement gLExec on the WN 3

Already since Update 10 of the SAM-Nagios software these tests can be enabled in the ROC/NGI profile,such that sites will be able to monitor the results along with those for other tests:

https://tomtools.cern.ch/confluence/display/SAMDOC/Update-10•

Monitoring gLExec services•

Note: such automatic glexec tests only cover CE services that have also been declared with a "gLExec" typein the GOCDB.Note: please declare your CE services that should receive the glexec tests!

To see the gLExec test results for all NGI/ROC instances:

MyWLCG gLExec summary •

LHCb also run such tests (currently only for LCG-CE services):

https://sam-lhcb-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CE&style=detail•

https://sam-lhcb-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CREAM-CE&style=detail•

CMS have developed a more elaborate test for which the results are published here:

https://sam-cms-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CE&style=detail•

https://sam-cms-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CREAM-CE&style=detail•

https://sam-cms-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_OSG-CE&style=detail•

ATLAS test results would be published here at some point:

https://sam-atlas-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CE&style=detail•

https://sam-atlas-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CREAM-CE&style=detail•

https://sam-atlas-prod.cern.ch/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_OSG-CE&style=detail•

More information

https://wlcg-tf.hep.ac.uk/wiki/Multi_User_Pilot_Jobs•

https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/GLExec•

Tracking GID for Condor/SGE/Oracle Grid Engine•

https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework•

The mailing list "wlcg-glexec-deployment" (with cern.ch as the domain) is available for site adminsto subscribe to and post questions.

For people with a CERN account: https://e-groups.cern.ch/e-groups/EgroupsSearchForm.do♦ To get a "lightweight" CERN account first:https://account.cern.ch/account/Externals/default.aspx

♦

•

-- MaartenLitmaath - 13-Apr-2011


Monitoring of gLExec tests 4

This topic: LCG > GlexecDeploymentTopic revision: r23 - 20-Apr-2012 - MaartenLitmaath

Copyright &© by the contributing authors. All material on this collaboration platform is theproperty of the contributing authors.Ideas, requests, problems regarding TWiki? Send feedback


More information 5

gLite Argus and Security Infrastructure Product Teams date 2010.06.02

Argus Authorization Framework and SCAS transitional service in gLite In this note, we attempt to explain the different options for a back-end authorization service in gLite. LCAS and

LCMAPS were used as an authorization system for many components. These two services were deployed

locally on each host where the authorization decision needed to be made. Some level of site-wide

synchronisation was provided by using a shared gridmapdir and pool accounts served by LDAP. LCAS and

LCMAPS provide Grid-to-Unix credential mapping using local or VOMS-based input; user, VO and group

banning; authentication validation; and credential life time limitations, etc. Also, several third parties have

extended LCMAPS with site-local or nationally developed plug-ins.

There are many scenarios where a centralised authorization service, that spans multiple site resources

(compute, resource brokering, etc.), is preferable. The most urgent use case for such a central service is the

use of identity switching and Unix-level sandboxing on the worker nodes in multi-user pilot job (MUPJ)

scenarios, implemented through the use of gLExec ‘on the worker node’.

Within gLite, two alternatives are currently available to sites: Argus and SCAS (‘site-central authorisation

service’). It is not always clear which of these two solutions (or both) should be preferred. Argus is the new

gLite authorization service, developed in EGEE-III, which is being interfaced to other gLite services to provide a

single authorization service at a site as part of the EMI work plan. SCAS is a networked service which allows

remote invocation of LCAS/LCMAPS instances for central evaluation and mapping. Of these, SCAS is intended

as a transitional solution, allowing sites to use site-central authorization whilst leveraging the existing

infrastructure and configuration known from the LCAS/LCMAPS system.

At this point in time Argus 1.1 provides all functionality that is needed for a ‘standard’ site in the EGEE grid to

perform site-central authorization, and at the same time provides a clear path forward for richer and more

flexible authorization decisions, also incorporating off-site policy if so desired.

Suggested deployment options

If: Sites that currently use Yaim exclusively for installing gLite

Then: continue to use Yaim as provided and deploy an Argus service node.

If: Sites that use LCAS/LCMAPS with only basic and VOMS plugins and only default ordering of the

LCMAPS policies, including those where secondary groups are used for authorization or accounting

Then: choose Argus as the preferred solution.

Then there are several exceptional cases:

Sites that rely on additional node-local credential mapping (e.g. AFS/K5 integration), or

Sites that use LCAS/LCMAPS modules that have site-wide effects (such as dynamic groups and

automatic LDAP updating),

Then: should consider to either (i) keep their node-local system but deploy in addition an Argus node

and use the LCMAPS PEP-C plug-in to support central banning, or (ii) deploy both SCAS and Argus and

use the (Yaim) functionality of ‘dual-call’ to both systems, if their credential mapping support and

benefits from a central service.

Sites that rely on complicated mappings such as many-to-one account mappings without VOMS and

ordering of mapping sequences

should contact the team to see if their use case is already supported by Argus. Some use cases may

already be supported. For use cases where non-VOMS proxies are used with pool account mappings,

or other more complex mappings, support will be prioritized following mutual agreement.

On the Argus Authorization Framework and the SCAS transitional service 2

Sites that use independently (third-party) developed LCAS/LCMAPS modules for credential mapping

based on local or national non-XACML policy systems or attributes that benefit from central

evaluation

should consider SCAS, but preferably configure also the ‘dual-call’ solution from the worker node.

Sites that fall in the category of the above described "exceptional cases" and deploy SCAS should contact the

Argus product team and describe their use-case such that the missing functionality can be added to Argus. The

Argus PT is committed to make Argus cover all possible deployment options.

When deploying SCAS with central credential mapping in conjunction (sequentially) with Argus, make sure to

call Argus first and disable the credential mapping features of Argus. The Argus ‘PEP daemon’ caches results so

that dual call is not expected to add significant overhead.

Issues and remarks

Through the standard use of LCMAPS plugins (pep-c client for Argus or the scas-client for SCAS), and in some

cases through service-native calls, all central authorization services (Argus or SCAS) can also be used in other

places where the authorization is currently done locally. On the other hand, not all possible scenarios and

combination have been (stress) tested. The use of Argus (or SCAS) with gLExec is a certified combination. The

use of SCAS with the lcg-CE (Globus GK/GridFTP) has been tested but is not certified, Argus in the same

position should work equally well. The integration of Argus into CREAM is currently been done and should

become available in fall 2010. In case desired site-local functions or capabilities are not (yet) present in Argus

Yaim supports configuring calls to both Argus and SCAS in selected configurations.

For local services that currently use LCMAPS, or when locally developed LCMAPS plug-ins are being used,

adding an additional call to Argus for additional (site-central) decision making is a straight-forward and

sustainable solution. Argus will over time add more advanced functionality, including execution environment

customisations and support for authorizing access to more diverse site-local resources such as VMs. Based on

site input and the issues reported, these features can be designed and prioritized for inclusion in Argus.

However, such services will not become available for SCAS, which has entered maintenance mode. Meanwhile,

SCAS will remain a supported component for as long as customers have it deployed in the operational

infrastructure and reported incidents will be analysed and processed.

Summary

Sites should install Argus 1.1, except in the special cases listed. Sites that have special LCAS/LCMAPS plug-ins or

configurations deployed as described in "suggested deployment options" should contact the Argus PT and

describe their use-case. The PT will then either recommend installing SCAS or Argus or both and advise on the

custom installation. If Argus lacks a required functionality, then it will be prioritized together with the site and

added in a future release.

A quick-selection guide for site administrators is also available on-line at

https://www.nikhef.nl/grid/gridwiki/index/Central_authorization_service

Support for gLite authorization issues is available at

[email protected]

GLEXEC(1) GLEXEC(1)

NAMEglexec- execute a command as another user based on grid credentials

SYNOPSISglexec[-b] <command> [arguments]

glexec<-h|-v|-V>

DESCRIPTIONgLExec allows a permitted user to execute a command as another normal user, where the identity change isbased on a X.509 proxy certificate. Whether a user is permitted to run gLExec is determined using thegLExec configuration file. The authentication and authorization is done by LCAS (optional) andLCMAPS. Only when the user is authorized and a valid mapping has been established will gLExec executethe specified command with its arguments. The command can either be specified as an absolute path, orwill be taken relative to the current working directory after the identity change.

gLExec can be installed in either user-switching (default) or logging-only mode. In logging only mode, noactual user-switch is performed, and hence the target executable will be run with the same credentials andpermissions as the calling user, but the mapping as it would have been done, will be logged. FurthermoregLExec will still fail in this mode if either LCAS or LCMAPS denies or fails.

gLExec clears all environment variables except those starting withGLEXEC_ and those explicitlywhitelisted in theglexec.conf(5). Variables starting withMALLOC_ cannot be whitelisted and will alwaysbe lost. Furthermore, note that the variableLD_LIBRARY_P ATH is ignored for setuid applications.Toovercome these limitations, one can use the glexec_wrapenv.pl and glexec_unwrapenv.pl scripts.A number of variables will be set up by gLExec for the target environment. See further underENVIRON-MENT for individual details.

OPTIONS-h, --help

Displays usage information.

-v, --verboseDisplays the version of gLExec.

-V, --definesDisplays the compile-time defaults. Only available for users root and glexec.

-b, --backgroundRun payload in the background.

ENVIRONMENT -- for gLExecGLEXEC_CLIENT_CERT

should point to a file containing a valid proxy on which the user switch will be based. This is typi-cally a proxy of the payload user. The file should be readable/writableonly by the calling user. If arelative path is specified it is taken relative to the current working directory at the time gLExec iscalled.

X509_USER_PROXYshould point to a file containing a valid proxy used to authenticate at an authorization service suchas a SCAS or Argus PEPd. This is a proxy of the pilot job user.NOTE: gLExec will reset this variable to a suitable proxy for the payload user.

GLEXEC_SOURCE_PROXYwhen set, the file it points to will be copied for use as proxy by the payload user. The file should bereadable/writableonly by the calling user. If a relative path is specified it is taken relative to the

gLExec 0.9.6 December 2011 1

GLEXEC(1) GLEXEC(1)

current working directory at the time gLExec is called. When unset it will default to the filepointed to by GLEXEC_CLIENT_CERT.NOTE: the automatic copying of a proxy for the payload user and setting up of the correspondingenvironment variables can be disabled by either setting the configuration optioncreate_tar-get_proxy to ’no’ or specifying ’/dev/null’ as GLEXEC_TARGET_PROXY.

GLEXEC_TARGET_PROXYwhen set, the file pointed to by GLEXEC_SOURCE_PROXY (or its default value) will be copiedto this location, with the credentials of the target user. The path has to beabsolute. When unset, itsdefault depends on the gLExec running mode, in user switching mode its default is a unique file-name /tmp/x509up_u<uid>.glexec.XXXXXX where <uid> will be the target uid and XXXXXXwill be 6 random letters. In logging only mode its default value will be equal toGLEXEC_SOURCE_PROXY or its default, butnofile will be copied.NOTE: the automatic copying of a proxy for the payload user and setting up of the correspondingenvironment variables can be disabled by either setting the configuration optioncreate_tar-get_proxy to ’no’ in the glexec.conf (for sysadmins) or specifying the GLEXEC_TAR-GET_PROXY=/dev/null (for pilot users).

SSL_CLIENT_CERT(deprecated)gLExec doesNOT use this variable, use GLEXEC_CLIENT_CERT instead. Itis the old style ofpassing a certificate, whereby the variable contained the whole certificate and not a path to a cer-tificate.

ENVIRONMENT -- for payloadThe following environment variables are set up during the execution of gLExec with sensible values for theexecution environment of the requested command:

PATH/usr/local/bin:/usr/bin:/bin

HOMEin switching mode, set to the home directory of the mapped user, e.g. /home/pool0001,in log-ging only mode it is set to the home directory of the calling user.

USERLOGNAME

in switching mode, both are set to the username of the mapped user. In logging only mode bothare set to that of the calling user.

X509_USER_PROXYset to value of GLEXEC_TARGET_PROXY or its default. In logging only mode, whenGLEXEC_TARGET_PROXY is unset, no file will be copied and this variable will point to thesame location as (the default of) GLEXEC_SOURCE_PROXY.

IMPORTANT: although for the payload users this variable is equal in value to GLEXEC_TAR-GET_PROXY, payload users should NOT rely on GLEXEC_TARGET_PROXY but only use thisX509_USER_PROXY variable.

GLEXEC_TARGET_PROXY (deprecated)Do not rely on this in the target environment. For the target user this variable has the samevalue as X509_USER_PROXY. It is only set for backwards compatibility and it is foreseen to beno longer set in a future version.


GLEXEC(1) GLEXEC(1)

ENVIRONMENT -- for epilogueThe epilogue executable (seeEPILOGUE below) will run with the same environment as the payload, withan additional set of environment variables starting with GLEXEC_EPILOG_. Hence all environment vari-ables set before the start of gLExec starting with GLEXEC_EPILOG_ will be removed from the environ-ment for the epilogue (but will be available to the payload). The list of variables setup for the epilogue exe-cutable are:

GLEXEC_EPILOG_GLEXEC_CWD startup directory of gLExec

GLEXEC_EPILOG_ARGC argc of payload

GLEXEC_EPILOG_ARGV<N> argv of payload

GLEXEC_EPILOG_GLEXEC_USER calling user username

GLEXEC_EPILOG_GLEXEC_GROUP calling user primary groupname

GLEXEC_EPILOG_GLEXEC_UID calling user uid

GLEXEC_EPILOG_GLEXEC_GID calling user primary gid

GLEXEC_EPILOG_GLEXEC_SGIDS calling user sec. gids, colon separated

GLEXEC_EPILOG_TARGET_USER target user username

GLEXEC_EPILOG_TARGET_GROUP target user primary groupname

GLEXEC_EPILOG_TARGET_UID target user uid

GLEXEC_EPILOG_TARGET_GID target user primary gid

GLEXEC_EPILOG_TARGET_SGIDS target user sec. gids, colon separated

GLEXEC_EPILOG_GLEXEC_PID gLExec process ID

GLEXEC_EPILOG_GLEXEC_SID gLExec session ID

GLEXEC_EPILOG_GLEXEC_PGID gLExec process group

GLEXEC_EPILOG_TARGET_PID payload process ID

GLEXEC_EPILOG_TARGET_PGID payload process group

GLEXEC_EPILOG_TARGET_RC payload exit code

RETURN VALUESUpon successful execution of a program, the return value fromgLExec will simply be the return value ofthe program that was executed. Otherwise,gLExecquits with the following limited range of return values:

201- Client error:This error code is triggered when the user (caller of gLExec) has to change something in order forgLExec to be able to succeed. Some example situations: the input files (like proxy certificates)might have the wrong permissions or do not exist; the payload to be executed doesn’t exist or hasunacceptable file permissions.

202- InternalgLExecerror:This error code has to be handled by the system administrator of the machine.This might be dueto wrong permission bits on the configuration file, initialization errors of LCAS and/or LCMAPSor other system specific errors that can only be addressed by somebody with sufficient rights onthe machine.


GLEXEC(1) GLEXEC(1)

203- Authorization error:Everything went ok, but the user is not authorized. This could be triggered because the callingprocess was not in the white list and therefore not privileged to use gLExec. The other reason isthat LCAS and/or LCMAPS failed to authorize the (real) user and gain an account mapping.

204- Child return value overlap:This error code is triggered when (in linger mode) the called child process returns an exit code thatoverlaps with one of the error code numbers 201, 202, 203 and 204.

126- Shell returns that the payload can’t be executed:This error code is triggered when the execve() call failed to execute the command, because of per-mission, execution or system problems found during the call for the payload that was tried to beset up. The shell code is not caught, but forwarded as an error code from the actual child process.

128+n- Child exited due to signaln.

LINGER MODEThis run mode is default, and the preferred setup. In this run mode, gLExec will run its payload in a subpro-cess and linger in the background. The lingering gLExec will keep running as the calling user, allowing thecalling (pilot) user to communicate with the payload via signals and allows running an optional epilogueexecutable. See further underSIGNAL HANDLING andEPILOGUE for details. Once the payload is fin-ished, the lingering gLExec will further run as root, log the accounting information and exit status of thepayload, and can optionally run anepilogueexecutable. The lingering gLExec will normally close all openfile descriptors apart from stdin/stdout/stderr, unless the optionclose_fdsis set to no. When linger mode isdisabled, gLExec itself will do an exec to run the payload.

SIGNAL HANDLINGNOTE: this section is exclusively valid from gLExec version 0.9 and higher.

Most of the signal handling is useful when gLExec runs inlinger_modeas it allows the calling user to sig-nal the payload or to end the payload in a clean way when gLExec receives a termination signal.

When gLExec receives aSIGTERM , SIGINT , SIGXCPU or SIGXFSZ, it will send aSIGTERM to itspayload or the epilogue when active and wait a configurable (via theterm_delayoption) gracetime for thechild to finish. If the child has not finished within that time it will send aSIGKILL . It will then wait anadditional configurable gracetime (via thekill_delayoption) for it to end, such that it can log the exit status.After that it will end itself. Since these gracetimes are implemented using the setting of an alarm, theSIGALRM is not available to the user.

When gLExec receives aSIGBUS, SIGFPE, SIGILL , SIGSEGV, SIGABRT , SIGSYSor SIGSTKFLT(where applicable), which does not originate from a user running e.g. kill -SEGV, it will send aSIGTERMto any childprocess it might have and exit immediately.

SIGTTOU andSIGTTIN are ignored in order to allow job control. SIGPIPE is logged and ignored.

Other signals, including real-time signals (SIGRTMIN till SIGRTMAX ) are logged and forwarded to thechild process. For the real-time signals andSIGTRAP, SIGEMT (on supporting platforms),SIGV-TALRM andSIGPROF this can be disabled using theextra_sighandlersoption, in order to allow the useof debuggers, profilers etc. They should normallynot be disabled.

gLExec tries to do jobcontrol for its payload. When it notices that its payloads suspends, it takes over thetty and prints a message on stderr, while returning the tty to the payload and printing again on stderr when it


GLEXEC(1) GLEXEC(1)

continues. SinceSIGTSTP (e.g. CTRL-z) andSIGCONT are forwarded, this allows the calling user tosuspend and continue the payload in a smooth fashion. At the same time it gives feedback for the callinguser when a job unexpectedly gets suspended.

When gLExec sendsSIGTERM or SIGKILL to its payload/epilogue, it will use their process group whenthe optionuse_setpgidis enabled (default) to prevent daemonization. Forwarding of signals is done usingthe process ID of the child.

EPILOGUENOTE: this section is exclusively valid from gLExec version 0.9 and higher.

gLExec can optionally run an epilogue executable after the payload has finished, typically to clean up afterthe payload has finished. Note that it is necessary that gLExec runs inlinger_mode. It is also advised thatthe userswitch is done by gLExec and not LCMAPS (user_identity_switch_byoption set to glexec, itsdefault).

The epilogue script or binary can be triggered by setting theepilogueoption to an absolute path to a root-trusted executable, i.e. an executable that cannot be changed by anyone but user root. It normally will run asuser root and group 0 (root or wheel). This can be overridden using theepilogue_userandepilogue_group.When either of these is specified, they will also be trusted. Using other user or group could be useful if theepilogue executable is located on an NFS with root-squash.

The epilogue will be run with stdin/stdout/stderr all redirected to/from/dev/null. Logging functionality isleft to the executable. gLExec provides the executable with an extensive set of environment variables pro-viding information about gLExec and the payload process. See underENVIRONMENT for details.

The epilogue will run for a maximum walltime which can be configured using theepilogue_timeoutoption.After this timeout, it will be sent aSIGTERM and/orSIGKILL . See further under theSIGNAL HAN-DLING concerningterm_delayand kill_delay. The epilogue should return an exitvalue of 0, otherwisegLExec will return with a 202 (internal error).Signal handling while the epilogue is active is identical tothat during the running of the payload, except that the lingering gLExec will normally run as root and hencehence only root can signal the epilogue.

INSTALLATIONNOTE: this section is exclusively valid from gLExec version 0.7 and higher.The preferred ownership for the glexec executable is root.root or root.glexec. For the config file, the pre-ferred ownership is glexec.root.

For switching mode, the preferred set of permissions for the executable is 4711 and for the config file 0400:-rws--x--x 1 root root 12345 2010-02-29 12:34 glexec-r-------- 1 glexec root 123 2010-02-29 12:34 glexec.conf

For logging only mode, the preferred set of permissions for the executable is 0711 and for the config file0444:-rwx--x--x 1 root root 12345 2010-02-29 12:34 glexec-r--r--r-- 1 glexec root 123 2010-02-29 12:34 glexec.conf

These setups also work when either or both are installed onNFS mounts withroot-squashenabled.

FILES/etc/glexec.conf


GLEXEC(1) GLEXEC(1)

BUGSReading and writing of proxy files will generally be done with either flock(2) or fcntl(2) locks. However beaw are that these mechanisms do not always reliably work on NFS file systems. See flock(2) for moredetails.

LIBRAR Y PATH NOTESThe effective library path of the system and shell must be able to locate the required runtime libraries forgLExec itself, LCAS, LCMAPS and their dynamically loaded plug-ins. In an ideal world this would meanto have all the required libraries be installed in system native locations on the file system. In practice it isusually necessary to add the paths/opt/globus/lib/ and/usr/lib64 to the run-time library search paths.

For gLExec versions 0.8 and higher, the location of the LCAS and LCMAPS dynamic libraries can be spec-ified in the glexec configuration file. However, note that these are not used to resolve second level depen-dencies (i.e. those needed by LCAS and LCMAPS themselves).

Since gLExec is a setuid application, LD_LIBRARY_PATH is ignored, see ld.so(8), so this leaves addingthe path to the /etc/ld.so.conf{.d/glite} file or directory or hoping for a correctly applied set of RPATH val-ues in the libraries. When using a version built by ETICS, only the ld.so.conf option is available sinceETICS strips the RPATH values in the libraries. If you build all the components from source withoutETICS, these RPATHs take precedence.

SEE ALSOglexec.conf(5), execve(2), ld.so(8), signal(7), flock(2), fcntl(2), glexec_wrapenv.pl(1),glexec_unwrapenv.pl(1)

http://wiki.nikhef.nl/grid/GLExec

AUTHORSWritten by Oscar Koeroo & Mischa Sallé (from Jan 2009)Written by Gerben Venekamp (until Jan 2009)

COPYRIGHTCopyright © 2009-2010 EGEE


GLEXEC.CONF(5) GLEXEC.CONF(5)

NAMEglexec.conf- configuration file for gLExec

DESCRIPTIONThe gLExec configuration file is a standard .ini file and by default located at/etc/glexec.conf. All gLExecspecific settings have to be listed under the [glexec] tag and although other tags are allowed, none otherthan [glexec] are taken into account.

The following key value pairs are currently understood by gLExec.

[glexec]

linger = {yes,no}Controls the behaviour of gLExec when executing the real user job. gLExec either forks, runs thereal user job in the child and wait for it to return, i.e. gLExec is said to linger, or gLExec will loadthe image of the real user job over that of itself, in which case it does not linger. Default:yes.

linger_as_payload = {yes,no}When gLExec runs in linger mode, it should linger under the account of the user that calledgLExec. This option overrides that and lets gLExec linger under the account of the actual payload.NOTE: do not use unless you know what you are doing. Default:no.

close_fds = {yes,no}When gLExec runs in linger mode, the lingering gLExec closes all open file descriptors (apartfrom stdin/stdout/stderr). If this causes problems for some reason, setting this option to no willprevent this. Default:yes.

use_setpgid = {yes,no}By default, in linger mode, gLExec runs its child processes in a separate process group, in order tobe able to better manage them. This option can be used to prevent using a separate process group.Default:yes.

force_payload_background = {yes,no}When gLExec runs in linger mode (seelinger), uses a separate process group (seeuse_setpgid)and stdin is a tty owned by gLExec, then gLExec normally hands over control of the tty to the pay-load (payload runs in foreground). When this option is set to yes, gLExec will not hand over thecontrol of the tty to the payload (payload runs in background). The gLExec calling user can alsoforce the payload into the background by specifying the -b flag on the command line. See alsotcsetpgrp(3). Default:no.

lock_mechanism = {flock,fcntl,disabled} (deprecated)Usetarget_lock_mechanisminstead.

target_lock_mechanism = {flock,fcntl,disabled}This option specifies the type of file locking used when writing the target proxy. By defaultflock(2) will be used. Alternatively fcntl(2) can be selected, which works better over NFS. Thirdlythe locking mechanism can be disabled.

input_lock_mechanism = {flock,fcntl,disabled}This option specifies the type of file locking used when reading the input proxies, i.e. theGLEXEC_CLIENT_CERT and the GLEXEC_SOURCE_PROXY. By default flock(2) will beused. Alternatively fcntl(2) can be selected, which works better over NFS. Thirdly the lockingmechanism can be disabled.

log_destination = {syslog,file}Tells where gLExec, LCAS and LCMAPS should send logging information to. For valuefile seealso next key log_file.NOTE: In logging-only mode, onlysyslogis allowed and will automatically be selected. Also incase opening of the logfile fails, that error will be logged to syslog.

glexec.conf 0.9.6 December 2011 1


The default issyslog.

log_level = {0,...,5}Set the log level cut off for gLExec. Higher means more logging, highest level includes debuginformation. See alsodiff_syslog_levels. Default is level 4.

syslog_facilityWhen set to a valid syslog facility, this will be used instead of the built in default. Seesyslog(3)for valid values. Default:LOG_DAEMON.

diff_syslog_levels = {yes,no}When logging to syslog (log_destinationis syslog), gLExec maps its own loglevels {0,...,5} ontosyslog levels {LOG_ERR,...,LOG_DEBUG}. Older versions of gLExec logged all messages onsyslog level LOG_ERR, whilelog_level only determined the amount of messages logged. Thiscan slow down execution considerably. By specifying no for this option, the old behaviour is used.NOTE: do not disable unless you know what you are doing. Default:yes.

log_file Specify which file gLExec should use in caselog_destination is set tofile. See alsolcas_log_fileandlcmaps_log_file. Default:/var/log/glexec/glexec_log.

log_file_groupWhen creatinglog_file and parent directories, use this group. The log file is created using permis-sions 0640, parent directories using 0750. Default:GID 0.

omission_private_key_white_listList of comma separated user names that do not have to present a private key in their certificatewhen calling gLExec (note: this applies only to the certificate or proxy that will be used forauthentication and authorization of the users calling gLExec, i.e. the GLEXEC_CLIENT_CERT,andnot the one that can be copied by gLExec).

preserve_env_variablesList of comma separated environment variables that gLExec will try to preserve in addition to theset of environment variables preserved by default. Eachname is matched as a whole, case-sensi-tive, string match.NOTE: Please note that not all environment variables can be preserved due to the way the linkermight work. In case of setuid executables, LD_LIBRARY_PATH is normally ignored by thedynamic runtime linker, see ld.so(8) and hence gLExec has no means of preserving it. In addition,all variables starting with MALLOC_ are removed for security reasons and cannot be preserved.

pedantic_security_checks = {yes,no}This option will enable a set of pedantic security checks: It will check whether the executable isNOT world writable and if the executable and directory are owned by either the calling user, targetuser (only in switching mode) or root. Default:No.

prohibit_exec_via_symlink = {yes,no}This option will disallow the execution of a command or executable that is symlinked. Default: No(which will allow the execution of a symlink)

user_identity_switch_by = {glexec,lcmaps}Determine where the target user identity is enforced. It takes either the value ofglexec, whichmeans gLExec will do the actual switching to the target uid, orlcmaps, in which case the actualswitching is left to LCMAPS. In case thelcmapsvalue is used, please take note of theBUGS sec-tion. NOTE: It is advised to let gLExec do the userswitch. Default:glexec.

user_white_listList of comma separated user names that are allowed to call gLExec, e.g.oscar,mischa,rootA single * is interpreted as everyone. Note that * cannot be used as part of a name.When the name starts with a dot, e.g..dteam, the name denotes a pool account and matches alluser names starting with dteam, followed by one or more digits. Thus.dteam matches the regularexpression: dteam[0-9]+. See alsogroup_white_list.



group_white_listAll users belonging to this group are allowed to call gLExec, even if they are not in theuser_white_list, see above. Default:glexec.

backlog_pathWhen a directory is specified for this option, backlog entries will be created.A backlog entry hasa filename consisting of the username of the target user followed by colon and the process id ofglexec; it has as contents the username of the calling user.NOTE: in order to create backlog entries, it is also necessary to configure gLExec to do the switch,seeuser_identity_switch_by.

create_target_proxy = {yes,no}By default, gLExec will setup environment variables pointing to a valid and reachable proxy forthe payload user, using as input the values of the variables GLEXEC_SOURCE_PROXY andGLEXEC_TARGET_PROXY or their defaults, seeglexec(1)for details. By setting this option to’no’ gLExec will ignore these variables, not copy a proxy file and not set theX509_USER_PROXY for the payload user. Default:yes.

term_delayIn linger mode, after gLExec receives a SIGINT or SIGTERM, it will send a SIGTERM to its pay-load. This option sets the gracetime in seconds for the payload to end before gLExec sends it aSIGKILL.NOTEfor Torque users: Torque has a builtin default of 2 seconds for its own kill_delay. It is advis-able to increase that to at least 10 seconds. Default:5 seconds.

kill_delaySee previous key term_delay. When payload did not finish within the gracetime after theSIGTERM and gLExec has sent it a SIGKILL, it will grant the payload an additional gracetime toend before gLExec will give up and exit, allowing it to log the exit status.This option sets thisadditional gracetime in seconds. Default:1 second.

extra_sighandlers = {yes,no}When set, gLExec will set signal handlers for real time signals (SIGRTMIN till SIGRTMAX) andsignals commonly used by debuggers and profilers (SIGTRAP, SIGEMT, SIGVTALRM and SIG-PROF). Default:yes.

epilogueIn linger mode, gLExec can optionally run a trusted executable, intended to clean up the payloadenvironment. The option should point to the absolute path of a trusted executable: it must not bepossible for anyone except the root user (or theepilogue_userand/or members of theepi-logue_groupwhen set) to change the executable. It will run as uid/gid 0,0 (unlessepilogue_userand/orepilogue_groupare set). If it does not finish within aepilogue_timeout, it will be send aSIGTERM. Seeepilogue_user, epilogue_groupandepilogue_timeout. For proper functioning itis advised that gLExec will do the userswitch.

epilogue_userWhen set, theepiloguewill be run with this user identity. In addition this user is allowed to havewrite permission for the epilogue executable (i.e. is trusted). This currently only works whengLExec does the userswitch. Default:root.

epilogue_groupWhen set, theepiloguewill be run with this group identity. In addition members of this group areallowed to have write permission for the epilogue executable (i.e. are trusted). When unset, theexecutable will be run with GID 0 and no group will be trusted. This currently only works whengLExec does the userswitch.

epilogue_timeoutThe epilogue executable will run for at most this timeout in seconds, before being sent aSIGTERM (and SIGKILL, seeterm_delayandkill_delay). Default:300seconds.



certdir The value of this option will be set as X509_CERT_DIR environment variable for internal use byLCAS and LCMAPS. If it does not point to an existing and absolute directory it will be ignored.

vomsdirThe value of this option will be set as X509_VOMS_DIR environment variable for internal use byLCAS and LCMAPS. If it does not point to an existing and absolute directory it will be ignored.

use_lcas = {yes,no}Make use of the LCAS framework or bypass it.NOTE: for LCMAPS versions < 1.4.23 it is still necessary to have LCAS installed, for later ver-sions of LCMAPS, this restriction is lifted.Default:yes.

lcas_libdirDirectory where to look for the LCAS dynamic libraries. When unset or set to a non-existingand/or relative directory, the default search mechanism for the dynamic linker is used (e.g.ld.so.conf). When set, versions of LCAS >= 1.3.15 will also look for the plugins in the directory<lcas_libdir><lcas_moduledir_sfx>. Seelcas_moduledir_sfx.

lcas_moduledir_sfxSuffix for the directory where lcas will look for the plugins. Seelcas_libdir. Default:/lcas.

lcas_db_fileOverride the built in location of the LCAS configuration file. Default:/etc/lcas/lcas-glexec.db.

lcas_log_fileOverride the built in location of the LCAS output log file. It can be the same aslcmaps_log_file,in which case both LCMAPS and LCAS use the same file to log to. Only used when logging desti-nation is file, seelog_destination. Default:/var/log/glexec/lcas_lcmaps.log.

lcas_debug_level = {0,..,5}Override the built in log level for LCAS. Default:4.

lcmaps_libdirDirectory where to look for the LCMAPS dynamic libraries. When unset or set to a non-existingand/or relative directory, the default search mechanism for the dynamic linker is used (e.g.ld.so.conf). When set, versions of LCMAPS >= 1.4.25 will also look for the plugins in the direc-tory <lcmaps_libdir><lcmaps_moduledir_sfx>. Seelcmaps_moduledir_sfx.

lcmaps_moduledir_sfxSuffix for the directory where lcmaps will look for the plugins. Seelcmaps_libdir. Default:/lcmaps.

lcmaps_db_fileOverride the built in location of the LCMAPS configuration file. Default: /etc/lcmaps/lcmaps-glexec.db.

lcmaps_voms_verification = {yes,no}Turn on/off verification of VOMS attributes by LCMAPS. Only available for LCMAPS versions>= 1.4.21. Default:yes.

lcmaps_get_account_policySpecify one or multiple LCMAPS plugin evaluation policies to be executed. This setting discardsall other policies configured in the lcmaps.db file. Use the policy names as written in thelcmaps.db file. In case of multiple policies, use the colon-character as a delimiter (the parsing ofthis string is performed by LCMAPS, not in gLExec). Example: "vomspolicy:oldstylepolicy"NOTE: The order of the configured policies is ignored by LCMAPS. The setting "policy1:pol-icy2" is equivalent to "policy2:policy1". The execution order is based on the order in which theyappear in the lcmaps configuration file (seelcmaps_db_file), which is read from top to bottom.



lcmaps_log_fileOverride the built in location of the LCMAPS output log file. It can be the same aslcas_log_file.Only used when logging destination is file, seelog_destination. Default:/var/log/glexec/lcas_lcmaps.log.

lcmaps_debug_level = {0,..,5}Override the built in log level for LCMAPS. Default:4.

EXAMPLESGlexec can be deployed in different scenarios and with each of these scenarios the content of the configura-tion files involved need to be changed.

Full mode:The first scenario in which gLExec can be deployed is the most common one and that is wheregLExec has set its suid bit and is called full mode. In full mode one can choose to log to syslog orto log to file. It is important that gLExec is installed with the following permissions and ownership:-rws--x--x 1 root root 12345 2010-02-24 11:07 glexec-r-------- 1 glexec root 123 2010-02-24 11:07 glexec.conf

The following example configuration file for gLExec can be use in case of full mode and loggingto syslog:

[glexec]log_destination = sysloglog_level = 4user_white_list = .dteam

The following example config file can be used for LCAS:

pluginname=/usr/lib64/lcas/lcas_userban.mod,pluginargs=ban_users.dbpluginname=/usr/lib64/lcas/lcas_voms.mod,pluginargs="-vomsdir /etc/grid-security/vomsdir -certdir /etc/grid-security/certificates -authfile /etc/grid-mapfile -authformat simple -use_user_dn

The following example config file can be used for LCMAPS:path = /usr/lib64/lcmaps

poolaccount = "lcmaps_poolaccount.mod"" -override_inconsistency"" -gridmapfile <grid-mapfile>"" -gridmapdir <gridmapdir>"

verify_proxy = "lcmaps_verify_proxy.mod"" -certdir /etc/grid-security/certificates"

glexec_get_account:verify_proxy -> poolaccount

In case logging to file is wanted, the following slightly altered gLExec configuration file can beused:

[glexec]log_destination = filelog_file = /var/log/glexec/glexec.loglog_level = 4user_white_list = .dteam









Logging only mode:gLExec can also run in logging only mode. In this mode gLExec will operate in almost the samemanner as in full mode with the difference that the suid bit of gLExec cannot be set. As a result ofthat, the identity switch can not take place due to missing privileges of the process and as far aslogging goes only syslog can be used. Use the following permissions:-rwx--x--x 1 root root 12345 2010-02-24 11:07 glexec-r--r--r-- 1 glexec root 123 2010-02-24 11:07 glexec.conf

In case gLExec was configured to let LCMAPS do the userswitch, the lcmaps_posix_enf pluginhas to be removed from the policy. In the case gLExec was configured to do the userswitch itself,no changes are needed in either configuration.

The gLExec configuration file might look like this:[glexec]log_destination = sysloglog_level = 5user_white_list = .glexec









Null mode:This mode has been discussed as one of the modes of gLExec. In this mode gLExec does not evenlog as opposed to the logging only mode. In this mode gLExec is virtually non existent. Actually,this mode can be implemented by the following script:

#!/bin/shexec $@

and as can be seen, gLExec is completely taken out of the equation and hence there is no need toconfigure either LCAS or LCMAPS as these libraries will not be called for.

INSTALLATIONNOTE: this section is exclusively valid from gLExec version 0.7 and higher.The preferred ownership for the gLExec executable is root.root or root.glexec. For the config file, the pre-ferred ownership is glexec.root.

For switching mode, the preferred set of permissions for the executable is 4711 and for the config file 0400:-rws--x--x 1 root root 12345 2010-02-29 12:34 glexec-r-------- 1 glexec root 123 2010-02-29 12:34 glexec.conf

For logging only mode, the preferred set of permissions for the executable is 0711 and for the config file0444:-rwx--x--x 1 root root 12345 2010-02-29 12:34 glexec-r--r--r-- 1 glexec root 123 2010-02-29 12:34 glexec.conf

These setups also work when either or both are installed onNFS mounts withroot-squashenabled.

FILES/etc/glexec.conf

BUGSLCMAPS has the ability to switch to a different uid through its posix_enf plugin (which is part of the basicplugin set). When this plugin is called from within a privileged environment, it performs the same useridentity switching as gLExec does. Versions up to and including 1.3.7 of this posix_enf plugin were toostrict in their checking for root capabilities. Since gLExec is not executed as real user root, but only effec-tively runs as root via its suid bit, the posix_enf plugin up to and including version 1.3.7 will fail. This hasbeen fixed for later versions of the posix_enf plugin.

SEE ALSOglexec(1) flock(2), fcntl(2), syslog(3) ld.so(8)

http://wiki.nikhef.nl/grid/GLExec

AUTHORSWritten by Oscar Koeroo & Mischa Sallé (from January 2009)Written by Gerben Venekamp (until January 2009)

COPYRIGHTCopyright © 2008-2010 EGEE


TITLE:GLExec System Administrator Guide

Date: May 24, 2012

This work is co-funded by the EC EMI project under the FP7 Collaborative Projects Grant Agreement Nr.INFSO-RI-261611.

glexec system administrator guide - nikhef · 2012-05-24 · using generic per-node pool accounts...

Documents