Hi,
The following is the result of a short discussion on the OAG list
(well, initially called "NA4/SA1 working group list"). Cal explained
the underlying problem - and requirement, hello JRA1 ;) - very well,
and I join his position in both the technical aspects and the
consequences for the VOs.
Rolf
Début du message réexpédié :
> De: Charles Loomis <[log in to unmask]>
> Date: 13 octobre 2005 16:28:54 GMT+02:00
> À: Rolf Rumler <[log in to unmask]>
> Cc: OAGlist <[log in to unmask]>
> Objet: Rép : VO software manager required?
> Répondre à: [log in to unmask]
>
>
> Hi,
>
>> Ok, let's go back to were it started from: on lcg-rollout there is an
>> ongoing discussion whether YAIM should issue an error message when
>> there is no VO software manager defined in the site-info.def file. So
>> my initial question was meant to clarify this technical issue.
>> Apparently you, Cal, also think that this decision is not a technical
>> one, which translates to: YAIM shouldn't rely on the existence of a
>> VO software manager.
>
> Ah, that thread in lcg-rollout; my mind is a bit slow today and I
> hadn't made the connection. Bottomline, yaim shouldn't rely on its
> existance to correctly configure a site and this shouldn't be a
> requirement on a VO to define it.
>
> I think that the root of this problem is much deeper, however. In my
> opinion a VO should be able to define groups and roles and assign
> rights based on those groups. The software manager problem is a
> specific instance of this: a VO defines a group called 'SGM' to which
> it assigns write access to a shared disk space provided by sites.
>
> The fact that the middleware doesn't uniformly support ACL-based
> (VOMS-based) access control is a serious limitation for applications.
> This is further exacerbated because there are no low-level middleware
> services which provide certificate-based access. E.g. disk access is
> based on unix user/groups and not on a user's DN. This causes a
> strict linkage between unix user/groups and VO-defined groups and
> severely limits the usefulness and flexibility of these groups.
>
> This is probably a point we should mark within the OAG as being
> extremely important and push the developers to provide a workable
> solution for this.
>
> Cal
>
|