1. Pilot Jobs John Gordon Management Board 23/10/2007

2. Pilot Jobs gLExec has been discussed many times –but Pilot Jobs are the deeper issue ¾ LHC VOs want them (and others too) –late binding of jobs –but there are sill many issues around trust and security Pilot jobs which download multiple payloads for the same user, the owner of the job, are not a big issue –apart from cleaning up between jobs –Multi-User Pilot Jobs present the problems.

3. Identity Change Current policies say jobs should run under the identity of their owners Multi-User Pilot Jobs break this policy unless they can change the identity of the job when they download new payload. gLExec is a solution to this. More later.

4. Policies A draft Grid Multi-User Pilot Jobs Policy document exists in draft 0.3 https://edms.cern.ch/document/855383/1 https://edms.cern.ch/document/855383/1 It contains the clause:- The VO must make a description of the architecture, the security model and the source code of their pilot job system available to Grid Security Operations and/or Sites on request. This will go out to wider consultation soon. We hope that it will constrain the actions of the VOs sufficiently to reassure the sites

5. Security Issues The details of the pilot job framework are as important, or even more important, than gLExec. We do need the experiments to document the details, not just provide access to the code. Significant security concerns related to not switching identities. The proxy of the pilot job owner is not protected from the owners of the user payload. A site which does not switch identities is putting the whole Grid at risk. MB "encouragement" to run gLExec in the setuid mode. If user credentials are transferred into the WN, then this has to be done securely This should really be done by proper delegation and with the user proxy being limited. We should require that gLExec is run in at least the Local authz/logging mode, and not allow the "do nothing" mode as there will then be no check that a user has not been blacklisted. Pilot jobs should not run at sites which do not run gLExec.

6. gLExec http://indico.cern.ch/materialDisplay.py?contribId=43&s essionId=26&materialId=slides&confId=3580http://indico.cern.ch/materialDisplay.py?contribId=43&s essionId=26&materialId=slides&confId=3580 http://indico.cern.ch/materialDisplay.py?contribId=92&s essionId=24&materialId=slides&confId=3580http://indico.cern.ch/materialDisplay.py?contribId=92&s essionId=24&materialId=slides&confId=3580 changes the identity of a running process subject to authorisation rules defined in LCAS/LCMAPS. Require gLExec is run in at least the Local authz/logging mode, and not allow the "do nothing" mode as there will then be no check that a user has not been blacklisted. Pilot jobs should not run at sites which do not run gLExec. setuid mode is contentious but arguably the most secure mode

7. gLExec Issues Middleware Ready? Certified? Security Audited? Library/server version? Configuration? Publishing? Site Antipathy

8. Next Steps The Grid Multi-User Pilot Jobs Policy needs to be finalised and approved. VOs need to publish their pilot job architectures for review by sites. gLExec-on-WN needs to be certified and included in the list of rpms for the WN. YAIM needs to configure gLExec and LCAS/LCMAPS to understand and authorise gLExec. gLExec status needs publishing in RunTimeEnvironment LCAS/LCMAPS server certified, configured and released. When we have the first 4 steps complete, VOs can start running generic pilot jobs at selected sites.

9. Site Antipathy Sites are reluctant to run setuid code on WN Gradually coming round to logging mode but this is less secure Not obvious if site management (computing or physics) backs their sysadmins over this Suggest a strong statement from MB requiring support for pilot jobs

10. MB Statements Sites that wish to support the LHC experiments need to make a (time-limited?) commitment to support pilot job execution. gLExec will be a mandatory part of the experiment pilot job frameworks. Non-compliance will then become an MoU issue between sites, their funding bodies and the experiments. While sites may have issues with running gLExec in setuid mode the MB believes that there are security problems running in non-setuid mode and so setuid should be mandatory. The MB requires experiments to publish a description of the distributed parts of their pilot job frameworks for review. The MB should ask EGEE TCG to prioritise gLExec-related deployment (how high?). Note that gLExec is already deployed in the OSG production release.

11. Of course if this is all too draconian for the MB then they can always refuse to accept pilot jobs and tell the experiments to go away and think again.