> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Matt Doidge
>
> Hello all,
> Thinking on this a little more I believe that this, err, request, may
> stray *slightly* from WLCG policy on the matter, in that we're being
> asked to implimate glexec user switching or bust. IIRC (and I could be
> wrong), the policy from WLCG allows for glexec(y) stuff to run in
> "logging-only" mode - as a second-best, we'd rather you didn't but it's
> better then naught - option.
>
My understanding is that 'logging only' mode doesn't meet the requirements of the EGI policy. The problem in a nutshell is that when you have (say) a worker node running two jobs for different users from the same VO and a bad thing happens (e.g. malware downloaded to the node, remote files wrongly deleted from storage, whatever) then you look at it and see files owned by 'gridpppilot023' then you can't tell which of the two jobs was responsible. All that 'logging mode' gets you AIUI is a local record of who the running jobs are supposed to be for - you still can't separate them. And that's purely a convenience since the same information should be available from the pilot framework anyway, it's just more hassle to go get it.
There are other ways of doing it than glExec; a namespace/container/VM based system that runs each job in a separate sandbox should be OK because a bad file created inside the sandbox can clearly only have come from the one job in the sandbox[1], and any bad network access must have been with the job's own credentials since it can't see into another user's sandbox to pinch theirs.
But fundamentally, if you and I are running in the same user account in the same system image at the same time, then I can do anything you can do, including using your proxy. And that's not good. Nor is it a policy compliance issue, it's a real one.
Ewan
[1] I'm deliberately considering the possibility of the sandbox failing as out of scope, just as we do the possibility of unix account separation failing in the normal case.
|