This page is under developement and will be updated to add more fine grained information -- it will contain more information on the installation and configuration details to install glexec, edg-gatekeeper, edg-gridftpd, gt4 gatekeeper and gt4 gridftpd.

Needed packages

This is the list of packages that is needed to get started

External / other packages

vdt-globus-essentials
glite-security-voms-api-c-1.7.11
gridsite-1.1.15-1.i386.rpm

LCAS

glite-security-lcas-1.3.7-1
glite-security-lcas-interface-1.3.6-1
glite-security-lcas-plugins-basic-1.3.2-2
glite-security-lcas-plugins-voms-1.3.3-1
glite-security-lcas-plugins-check-executable-1.2.0-1

LCMAPS

glite-security-lcmaps-1.4.2-1
glite-security-lcmaps-plugins-basic-1.3.7-1
glite-security-lcmaps-plugins-voms-1.3.7-1
glite-security-lcmaps-plugins-verify-proxy-1.2.8-1

For glexec

glite-security-glexec-0.5.23-3

For edg-gatekeepers and edg-gridftpd

edg-gatekeeper package
edg-gridftpd package

For Globus Toolkit 4.0.x Gatekeeper and/or gridftpd

This package implements the GT4.0.x mapping_and_authz interface, which is used to invoke LCAS and LCMAPS.

lcas-lcmaps-gt4-interface-0.0.13-1

Installation

gLExec installation notes

Set library paths correctly for the libs

After having successfully installed all the packages. You'll need to perform a check with

ldconfig

to see if all the packages can find all that is needed on the system.

Potentially you'lle need to add directories to the /etc/ld.so.conf or LD_LIBRARY_PATH. In this sense I can think of /opt/globus/lib and /opt/glite/lib(64).

The setup of gLExec

Create the compile-time set logdirectory:

mkdir /var/log/glexec/

If wished to gain the identity separation by mapping real user job to the target identity, then you should set the sticky bit of glexec on root:

chmod 4755 /opt/glite/sbin/glexec

Add a user 'glexec' with the group 'glexec' to the system. This account is used to read glexec.conf with lower-privileges.

Also members of the glexec group may execute glexec. All other users need to be whitelisted in the glexec.conf file.

The glexec.conf file

GLExec will read the glexec.conf file to determine how it should call and execute LCAS and LCMAPS. It also determines the run-time mode of glexec and which (set of) users are authorized to execute gLExec.

/opt/glite/etc/glexec.conf:

#
#  Glexec
#
[glexec]
lcmaps_db_file               = /opt/glite/etc/lcmaps/lcmaps-suexec.db
lcmaps_log_file              = /var/log/glexec/lcas_lcmaps.log
lcmaps_debug_level           = 5
lcmaps_log_level             = 5
lcmaps_get_account_policy    = glexec_get_account
lcmaps_verify_account_policy = glexec_verify_account

LCMAPS will be setup to use the stated lcmaps.db file. This lcmaps.db file looks very much the same as that of an gatekeeper, but differs in the plug-in execution policy. The set of plug-ins that is executed and required to function is different. LCMAPS will use the stated logfile, in this case in conjunction with the LCAS log. The lcmaps_get_account_policy parameter states which specific LCMAPS plug-ins execution policy will be used to perform the identity switching aka mapping. The lcmaps_verify_account_policy is the LCMAPS plug-ins execution policy that will be used to perform the verification (only Authorization) of the users' credentials.

lcas_db_file                 = /opt/glite/etc/lcas/lcas-suexec.db
lcas_log_file                = /var/log/glexec/lcas_lcmaps.log
# lcas_debug_level             = 1

These options are similar of the LCMAPS options. The specific lcas.db file will be called for the gLExec executions and it will use the stated log file.

linger                       = yes

The linger option dictates if the glexec executable will stick around in the process table or if glexec's execution image will be overwritten by the called execv (man 3 execv). With linger=yes, glexec will fork() and wait() for the child process to finish the execution (with execv). Is allows glexec to record the used real/cputime from the child process. With linger=no, then glexec's final command will be the execv() command to overwrite its own image with the called execution. The linger=no option is required by the Condor Glite-ins. If there is no strong reason for the linger=no configuration, it is advised for clarity reasons to use linger=yes. In that case you can easily track the glexec invocations.

silent_logging               = no
log_level                    = 1

These are logging settings of glexec itself.

user_white_list              = glexec*, venekamp, .mypool, root, okoeroo, uschwick, .atlaspilot

There are two groups of Unix accounts that may execute gLExec:

1. users that are part of the 'glexec' Unix group on the system.

2. A pool of user account or individual user accounts that are white listed.

3. Everybody can execute gLExec. This requires some other mechanism to authorize the decision making here.

The chosen string 'glexec' can be altered at compile time. If a user is associated to the 'glexec' group as a primary or secondary Unix group, then that is interpreted by gLExec as an authorized gLExec executor.

For category two your current Unix account must be matched in this list of authorized user accounts. You can state individual accounts or pool accounts in the same notation as known from the LCMAPS grid-mapfiles.

A statement like: pool* is equal to .pool What it means is that the string 'pool' may only be followed by digits. This is the same behavior as in reading the grid-mapfile and selecting poolaccounts.

In a CE like situation we imagine to authorize only one or a limited set of Unix accounts to be authorized to execute gLExec, like the Tomcat Unix account. All other accounts are prohibited to launch and use gLExec. The same concept applies to Pilot Job environments.

When a user launches the pilot job framework on a cluster, it will be mapped by the Computing Element to a certain account. If distinguishable in the user's carried credentials, the mapping at the CE can be made as such that it will be mapped to a specific poolaccount that represents the fact that the users has the privilege to launch pilot jobs. For instance the user might have been mapped to 'atlaspilot001'. Then the idea is that this pool called 'atlaspilot' is in the whitelist (see example above) and thus the pilot job launcher may execute gLExec.

The atlaspilot001 user account also have been added to the 'glexec' Unix group to gain the same type of access. In effect the decision to make the mapping to that pool of accounts gained the user the privilege to use gLExec.

preserve_env_variables       = MY_BULLSHIT_ENV

All environment variables will be scratched. Only the environment variables that are listed here will be kept and pushed into the (child) process that is executed by gLExec. The only two exceptions are $HOME and $X509_USER_PROXY. The $HOME will be scratched, but the called process will get a new $HOME environment that belongs to the mapped user account. This information is fetched from the password file. The $X509_USER_PROXY will be set to the location of the proxy certificate of the mapped user account.

#
#  LCMAPS configuration space
#
[lcmaps]

#
#  LCAS configuration space
#
[lcas]

There are no values to be set in these already preserved sections.

The setup of LCAS

LCAS configuration file: lcas.db

/opt/glite/etc/lcas/lcas-suexec.db:

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

The setup of LCMAPS

LCMAPS configuration file (for gLExec): lcmaps.db

/opt/glite/etc/lcmaps/lcmaps-suexec.db:

path = /opt/glite/lib/modules

posix_enf = "lcmaps_posix_enf.mod"
" -maxuid 1"
" -maxpgid 1"
" -maxsgid 32"

localaccount = "lcmaps_localaccount.mod"
" -gridmapfile /etc/grid-security/grid-mapfile"

poolaccount = "lcmaps_poolaccount.mod"
" -override_inconsistency"
" -gridmapfile /etc/grid-security/grid-mapfile"
" -gridmapdir /etc/grid-security/gridmapdir"

verify_proxy = "lcmaps_verify_proxy.mod"
" -certdir /etc/grid-security/certificates"
" --max-proxy-level-ttl=0 12:05"
" --max-proxy-level-ttl=L 12:05"
" --max-proxy-level-ttl=1 12:00"
" --max-voms-ttl 12:00"
#" --only-post-verify-checks"
#" --allow-limited-proxy"
#" --max-proxy-level-ttl=<level> <time-length; example: 2d-13:37>"
#"   Sets a maximum lifetime for proxy certificate level <level> where <level> can be 0-9 or 'l' or 'L' to indicate a Leaf proxy (last proxy in the chain)"

vomslocalgroup = "lcmaps_voms_localgroup.mod"
" -groupmapfile /etc/grid-security/groupmapfile"
" -mapmin 1"

vomspoolaccount = "lcmaps_voms_poolaccount.mod"
" -gridmapfile /etc/grid-security/grid-mapfile"
" -gridmapdir /etc/grid-security/gridmapdir"
" -override_inconsistency"

good = "lcmaps_dummy_good.mod"
bad  = "lcmaps_dummy_bad.mod"

# policies
glexec_get_account:
verify_proxy -> vomslocalgroup
vomslocalgroup -> vomspoolaccount

LCMAPS configuration file (for GT-based Gatekeepers & GT4 gridftpd): lcmaps.db