Hi Ewan,
Fair point, I agree :D
With large VO’s pragmatically this is mitigated somewhat by their monitoring, for instance (in the case in Atlas) you can always work back from a JOBID to a panda submission and cross check the user who submitted the job. Although as you suggest that only acts for identification and traceability not for protection on the worker node itself, and is also dependent on the monitoring available (for instance I can’t trace a user via LHCb’s portal as I’m not a member of that VO).
I think in general I think this is why cloud platforms have become such a success in a commercial setting, a VM is almost entirely isolated from any other VM's along with the processes inside. Well that and it’s usually easier to track someone down who's done something naughty when you have their credit card details and billing address!
Thanks,
Gareth
> On 7 Aug 2015, at 11:44, Ewan MacMahon <[log in to unmask]> wrote:
>
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Gareth Roy
>>
>> b) To run small VO workloads sites are now required to have glExec as the
>> pilot can’t guarantee safety without it in a multi-VO environment
>
> I think that's a fair summary, but I would quibble a little with this bit; while they're not identical situations, the pilot can't guarantee safety without glExec in a single-VO case either, there is still a requirement to separate a single VOs users from each other and from that VOs pilot credentials, and that also means that sites will still need glExec, or something else to do the job.
>
> I can't see that there's any way forward where we don't need something that does this, glExec or otherwise.
>
> Ewan
>
|