Hi Yves,
>>[...] The issue with static accounts is that the
>>audit trail gets fuzzy when 2 DNs have concurrent jobs on a particular WN,
>>running under the same account. It is like allowing a bunch of users to
>>share a single account and run jobs like that on your farm: do you allow
>>that for local users? If not, why should grid users be an exception?
>
>
> Yes, we do allow that for special accounts, like the root account, i.e.
> a user with a special task and a special role.
Sure, and to some extent it can be defended that sgm (and prd) accounts
should also fall in such a category, though from the site point of view
they are just normal users that happen to have write access to some area
whose contents are managed by the VO instead of the site.
To make matters worse, the sgm/prd users are grid users, not affiliated
with any site at all, whereas normally a site would only give special
privileges to users that signed an AU agreement with the site.
> In the VOMS world, there are two possibilities implementing the tasks of
> production and software manager:
> - either as roles (e.g. CMS and Atlas)
> - or as groups (e.g. LHCb)
That distinction is irrelevant for the current discussion. In both cases
there are _multiple_ people that can exercise the privileges concurrently.
The following commands are equivalent in that sense:
voms-proxy-init -voms atlas:/atlas/Role=lcgadmin
voms-proxy-init -voms lhcb:/lhcb/sgm
We advised LHCb against their choice, because each VOMS group is _always_
put into the proxy, whether you asked for it or not. It just happens that
for the time being mostly the _first_ FQAN matters, but already there is
more and more software that also looks at secondary FQANs, e.g. LFC and
DPM. This means that LHCb sgm people may accidentally exercise their sgm
privileges when working as a normal users.
A VOMS role is never automatic: you must specify it on the command line.
It is like doing an "su" or "sudo".
Thanks,
Maarten
|