Hi John,
> a) running multi-user pilot jobs with glexec in null mode breaks all
> policies and good practice for identifing who is responsible for work on
> your site. Who would you all have been whinging about if you couldn't
> anthropomorphise the RSA jobs.
This is almost true ... you do have the logging information although
this is not very strong
>
> b) glexec in logging mode leaves user jobs running with the identity of
> the pilot job framework. ie the ability to run glexec and access to the
> proxies, work and data of all the other users running under the
> framework on the same WN.
This is indeed a significant problem.
>
> That leaves glexec in setuid mode or not running multi-user pilot jobs.
> If no sites agree to this the experiments will have to find other ways
> to do their computing.
Or no pilot jobs under this sort of model.
>
> The WLCG Management Board endorsed the policy with a few small changes.
> There are a number of prerequisites like security reviews of glexec and
> the experiment pilot job frameworks and it will not take effect until
> the MB is happy with the outcome of them all.
>
Does this make it true? Just because the management board endorses the
policy doesn't make it right. While I know some site admins who are
ambivalent about this I know of none who are strongly in favour and
clearly there are plenty who are strongly against. Do their opinions
have no weight in this? Personally, I am ambivalent but I am no longer
directly a sys admin.
> Not having root access to WNs is not really an argument. No-one expects
> such frameworks to run on a cluster without the knowledge of the cluster
> owners. The idea is that someone (The experiments, WLCG, GRIDPP?) should
> negotiate with sites to get the pilot job frameworks (not just glexec)
> running as part of the installed software on a cluster. Reviews of the
> framework and software are all supporting evidence for those
> negotiations.
>
Actually, this is a real problem. It is one thing to set up a machine
that we own and have root access to that can submit jobs to the queues.
It is quite another setting up suid executables on the shared WN. You
can argue all you like that there isn't that much difference and that
they are opening up lots of security holes by letting external users on,
and you would be right. However, allowing things that can suid is a
whole new league ... and we all know it. I think that it will be a long
long time before anybody allows his on our ICT or UCL Central's
resources ... two large clusters.
Still as Stephen points out CMS should do well out of this. It is an ill
wind and all that.
All the best,
david
|