 |
 |
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 --------------------------------------------