Bug 6109 - Add ability for setuid programs to be plugged into GRAM4
: Add ability for setuid programs to be plugged into GRAM4
Status: RESOLVED WONTFIX
: GRAM
wsrf managed execution job service
: development
: Macintosh All
: P3 enhancement
: 4.2.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-05-29 13:35 by
Modified: 2012-09-05 11:43 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-05-29 13:35:42
A new feature request coming from OSG and the privilege project
(privilege_project@fnal.gov) is the ability to start a user's job under a
specific uid, gid, and multiple secondary gids.

A new security authorization callout (separate from this effort) will return
this information which will then be passed down to the setuid program, glexec.

Currently, sudo is hard coded in the MEJS java code.  Changing from sudo to
glexec needs to be configurable.  How best to enable this needs to be
investigated.  For example, the path to the setuid program should be
configurable, but does it make sense to also add configuration parameters for
setting environment variables / arguments for calling these programs?

Are there other setuid programs that should be considered besides sudo and
glexec?

Below are some details on executing the glexec program. 
export GLEXEC_CLIENT_CERT=<file path>
<abs path>/glexec <cmdline>

glexec will use the proxy to make the authz decision and the mapping, cleans
the environment and starts the <cmdline> as the new UNIX identity.

For GRAM4 purposes, a glexec plugin will be written that effectively ignores
the proxy and uses env variables for the mapping.

For example:
  GLEXEC_UID=<bla>
  GLEXEC_GIDs=<bla1,..,blaN>

GRAM will set those variables and launch glexec

Timeframe: 6 months would be acceptable - so by Dec 08.
------- Comment #1 From 2008-05-29 16:32:05 -------
The point of this (use case) is to make the file system (dirs and files)
accessible by certain groups and not accessible by others. For example, some
files are made readable only by a certain GID: if you are part of a VO group
that has privileges to access those files, then the authorization call-out will
add that GID to your account as one of your secondary GIDs; thus, you'll be
able to read the file.
------- Comment #2 From 2012-09-05 11:43:52 -------
Doing some bugzilla cleanup...  Resolving old GRAM3 and GRAM4 issues that are
no longer relevant since we've moved on to GRAM5.  Also, we're now tracking
issue in jira.  Any new issues should be added here:

http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363