GLExec

gLExec is a program that acts as a light-weight 'gatekeeper'. gLExec takes Grid credentials as input. By taking the local site policy into account it authenticates and authorizes the credentials. For extra safety gLExec is capable of creating a new execution sandbox based on the Grid credentials. Besides the yes/no control point functionality in the logging-only mode it can create identity specific sandboxes in the identity-switching mode.

Deployment: Installation and setups

• gLExec on the Worker Nodes
  • Using generic per-node pool accounts or a shared map database
  • Using the SCAS
  • Batch System Interoperability
• Deployment Scenarios in EGEE and OSG
• Secure installation considerations
• Debugging hints

How To's and FAQ

• How To's: To help you master the obstacles of gLExec's security:
  • GLExec TransientPilotJobs describes how you may go about managing a target workload's transient area in Pilot Job Frameworks.
  • GLExec Environment Wrap and Unwrap scripts describes how you can preserve the environment variables between the calling process of gLExec and the user switched side of gLExec. For example: to preserve the environment variables from a Pilot Job Framework, through gLExec and into Pilot Job Payload.

• FAQs and misconceptions about gLExec

Online documentation (on other sites)

• Exit codes of gLExec
• Man pages of gLExec
• Service Reference Card for gLExec

gLExec is a program to make the required mapping between the grid world and the Unix notion of users and groups, and has the capacity to enforce that mapping by modifying the uid and gids of running processes. It used LCAS and LCMAPS for access control and the mapping engine. It can both act as a light-weight 'gatekeeper' replacement, and even be used on the worker node in late-binding (pilot job) scenarios. Through the LCMAPS SCAS client a central mapping and authorization service (SCAS, or any interoperable SAML2XACML2 service) can be used.

The description, design and caveats are described in the paper to the CHEP conference.

Local services, in particular computing services offered on Unix [5] and Unix-like platforms, use a different native representation of the user and group concepts. In the Unix domain, these are expressed as (numeric) identifiers, where each user is assigned a user identifier (uid) and one or more group identifiers (gid). At any one time, a single gid will be the .primary. gid (pgid) of a particular process, This pgid is initially used for group-level process (and batch system) accounting. The uid and gid representation is local to each administrative domain.

Deploying gLExec on the worker node

Need to Know's

The gLExec executable is installable in two ways, with an without the setuid (file system) bit on root. With the 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 and exploitation by anybody who executes it. As gLExec is typically installed with a setuid bit on root, this effectively means that anybody on the system is able to execute something with root privileges for a brief moment of time to perform the user switch.

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 removed from the process environment by the Operating System before the first line of gLExec code is executed by a Unix and Linux system. Only the /etc/ld.so.conf{.d/}, RPATH settings and other system 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. There are a couple of environment settings that can easily lead to a root exploit in the standard library of a Unix and Linux system. Only the GLEXEC_* environment variables are kept. There is an option in the glexec.conf file to preserve more variables, but these must be selected with great care and setup by each System Administrator on all their machines.

• If the target user is authorized and when a mapping and Unix process identity switch the HOME and X509_USER_PROXY will be rewritten. Their value will contain the paths that are relevant for the target user account.

• The target user process has the Unix identity as mapped by LCMAPS. This could be from a separate set of pool accounts, or the regular set of pool accounts as given by the same user credentials from an LCG-CE or CREAM-CE. It could be a poolaccount defined locally on the machine. The only assumption that holds is that the target user account has the privileges that are appointed to them by the local site administrator.