Hi Yves,
Although I am not very happy with the deployment procedure and especially with
the quality of the release notes for updates, it is clear that new scheme is
much better than the old one. Since both VOMS roles and groups can (and
actually do) contain more than one user, from security point of view it is
desirable to map each such user to a different pool account at a given time.
This should have been done long time ago, but it is good that it is finally done.
I believe that it is worth investing effort in configuring your site (and for
DESY it certainly means a lot of effort!) this way - I did it and no problems
with the setup once I figured out what should be done :)
Best regards, Antun
-----
Antun Balaz
Research Assistant
E-mail: [log in to unmask]
Web: http://scl.phy.bg.ac.yu/
Phone: +381 11 3713152
Fax: +381 11 3162190
Scientific Computing Laboratory
Institute of Physics, Belgrade, Serbia
-----
---------- Original Message -----------
From: Yves Kemp <[log in to unmask]>
To: [log in to unmask]
Sent: Thu, 3 May 2007 10:31:32 +0200
Subject: Re: [LCG-ROLLOUT] the usual config disaster
> Hi Maarten,
>
> thanks for your email, I have a few comments:
>
> > > Have there been any security incidents in the past that forced the
> > > implementation of the new mapping accounts?
> >
> > No, but bad things should not be required to happen first, before we do
> > something about their cause. 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.
>
> 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)
>
> I do not know the reasons why they implement it like that, but I
> guess, there are reasons behind it. That is why I would prefer
> mapping one VOMS-role to one Unix-user and one VOMS-group to one
> Unix-group with different Unix-users.
>
> > It is true there are other risks that do not get mitigated by mapping
> > each sgm to an sgm pool account. For example, one hacked sgm account
> > can still be used to put a trojan horse in the shared software area.
> > One could argue that the situation thus remains fundamentally broken.
> > Does this mean we do not have to care about the static accounts?
>
> You are right, if the certificate of a sgm person is hacked, he could
> install a trojan horse or the like. In the "group" scenario, one
> could easily identify the culprit, whereas in the "user" scenario,
> this is difficult if not impossible. In the normal running, the
> "user" scenario allows for more privacy of data and software than
> the "group" scenario would. Privacy might be of lower importance in
> HEP, but other communities certainly will not tolerate this.
>
> Again, I guess that the VOs knew about these issues, when they
> implemented the different tasks. I do not know if the site admins should
> ignore their will.
>
> > > Is there any possibility to use the old mapping scheme?
> >
> > At the moment YAIM only allows exceptions for the VOBOX and SE_castor.
> > You could modify the functions that impose these requirements, but we
>
> Thanks for the hint!
>
> > think it is more constructive to "bite the bullet" now and shake the bugs
> > out of the current implementation. Or convince the Grid Deployment Board,
>
> As you can see from my emails, many things are not clear to me (and
> probably also to others). So, before we change our settings (which
> are difficult to change in case of DESY), I would like to get a
> better understanding of what I do. Especially, I would like to know
> what the VOs really want. Their current technical implemantations
> might not reflect this.
>
> > or WLCG Management Board, or EGEE Technical Coordination Group that it is
> > wrong to try imposing these requirements on all sites. Here I note that
> > it would be better for the VOs if all sites had a consistent configuration,
> > and there are some sites for which the sgm pool accounts finally solve a
> > longstanding security concern...
>
> I agree with you that a consistent configuration is better for all
> involved parties.
>
> Best
>
> Yves
>
> --------------------------------------------
> Yves Kemp
> [log in to unmask] Desy IT 2b/312
> Fon: +49-(0)40-8998-2318 Notkestr. 85
> Fax: +49-(0)40-8994-2318 D-22607 Hamburg
> --------------------------------------------
------- End of Original Message -------
|
