Glexec
From SysadminWiki
glexec is an extended version of apache suexec. It takes as input a certificate chain, possibly with VOMS extensions, a user program name & arguments to run; it checks authorization (LCAS, GUMS), user credentials, proper VOMS attributes, executable name; it acquires local credentials and a local (uid, gid) pair and it possibly enforces the local credential on the process. It is basically a suid program. It is used on the glite CE to change identity of the grid user before job submission and this led to idea of using it on the WN to implement traceability and Intra-VO accounting for pilot jobs
Pilot job lands on the WN, calls glexec, gives it a chain of delegated credentials of the "real" user it checks the user is allowed to run on the system against lcas/lcmaps logs the DN and then it setuid to another pool account and run the job as the latter. Policy and mappings should be uniform across the WNs so to make it work: glexec configuration files and a jobRepository that logs the mappings have to be shared by all the WNs.
To use glexec the VO submission framework has to know at least about credential delegation. This should be implemented by the VO. At the moment they are not implementing delegation but using gridftp to copy proxies from the VO scheduler to the WNs.
glexec can be used in 3 different modes
- It can be disabled replacing the glexec call with the null operation. In this case the pilot jobs will run all the jobs under its owner ID. This is currently the case.
- It can just check the real user is authorised and logs his credentials but the job still runs under the pilot job owner UID.
- It checks the real user is authorised and logs his credentials and it setuids to another UID. So the pilot job UID and real job UID are different.
3. is needed to satisfy pilot jobs traceability requirement #3 from sites. It is also needed by the VOs. As the pilot jobs run with a service proxy that should never be used by the users.
From the experiments point of view without 3. what a VO pilot job can do is limited a lot. Since the pilot and the user run under the same UID, the proxy the pilot used to fetch the user job must be destroyed before the user job starts, or the user could use it to act as the pilot job! And most pilot jobs rely on keeping in touch with the central repository for the life of the job, if nothing else, to notify it when the job ends.
More information about gLExec can be found here: gLExec - a grid enabled account mapping utility (http://www.nikhef.nl/grid/lcaslcmaps/glexec/).
