Difference between revisions of "LCAS and LCMAPS installation for gLExec and (GT4) gatekeepers"

From PDP/Grid Wiki
Jump to navigationJump to search
Line 117: Line 117:
  
 
There are two groups of Unix accounts that may execute gLExec:
 
There are two groups of Unix accounts that may execute gLExec:
1. users that are part of the 'glexec' Unix group on the system. The chosen string 'glexec' can be altered at compile time.
+
1. users that are part of the 'glexec' Unix group on the system. The chosen string 'glexec' can be altered at compile time.
2. A pool of user account or individual user accounts that are white listed
+
2. A pool of user account or individual user accounts that are white listed
  
 
If a user
 
If a user

Revision as of 16:13, 28 November 2007

-- This page is under developement and will be updated to add more fine grained information -- It will contain 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

There are two groups of Unix accounts that may execute gLExec: 1. users that are part of the 'glexec' Unix group on the system. The chosen string 'glexec' can be altered at compile time. 2. A pool of user account or individual user accounts that are white listed

If a user


Specially selected group

ways of executing gLExec,: - The calling The user_white_list values list the Unix accounts that have the permission to execute gLExec. If the user account that is calling gLExec isn't in the list then the two other options to be permitted to execute gLExec is The executing user could


preserve_env_variables       = MY_BULLSHIT_ENV
#
#  LCMAPS configuration space
#
[lcmaps]
#
#  LCAS configuration space
#
[lcas]