FAQs and misconceptions about gLExec
Here is a list of common question and misconceptions regarding gLExec.
Question : Is gLExec similar to sudo?
Answer : No. Sudo is generically meant to execute a program or script with root-privileges. gLExec will not perform any task besides the actual user switch with root-privileges. All operational tasks within gLExec are performed with the privileges of either the calling (system/Unix) user (e.g. reading the proxy), the glexec user/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 Grid credential 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 to perform 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.
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 all job types. Please have a look at the Batch System Interoperability experiences with different types of Batch Systems 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 right configuration settings for the mapping process to function properly and will need to install gLExec with the required setuid-bit enable on the binary with the root owenership.
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 the user process calling gLExec and the executed command with the target identity are unable to use gLExec's privileges. Multiple build-in security measures prevent a target user to be mapped to a root account or root group.
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 frameworks have moved the front door of your site from the CE to the WN. gLExec on the Worker Nodes gives back control to the Sites which they have on their CEs and regular jobs. With the identity switching feature enabled it can give the VOs the opportunity to not be regarded as one user i.e. when one user in the VO goes rogue the entire 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 this restriction.
We offer a few options from within gLExec:
- Per account white listing: In the glexec.conf file write user_white_list = okoeroo
- Per pool of account white listing: In the glexec.conf file write user_white_list = .atlpilot
- By letting the calling account be a member of the special Unix group 'glexec'.
- You could whitelist every account by using the wildcard *. There are good motivations why you want to do this and it should not blindly be regarded as a security risk. Please read ahead in the motivation section for details about this.
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 for an authorization decision, followed by LCMAPS which is able to call remote services like SCAS, GUMS or Argus for an authorization decision.