 |
 |
On 26 July 2012 11:56, J Nebrensky <[log in to unmask]> wrote: > Hi, > >>> From: GRIDPP2: Deployment and support of SRM and local storage management >>> [mailto:[log in to unmask]] On Behalf Of Jens Jensen >>> Sent: 25 July 2012 10:00 >>> >>> OTOH you may actually want to protect the file from being read by joe >>> random certificate user. We may need to figure this out before the VOs >>> will be keen on us providing https interfaces? > > Of course with the move to making data public, some VOs may be happy to have anyone (even literally) able to download the data... > > Possibly this is my own flawed impression, but there does seem to be some inconsistency between different bits of middleware as to how individuals, VOMS roles, VOMS groups, arbitrary VO members, and the world in general are mapped on to the user-group-any scheme that underlies the access control. > Yes, this is the case. In particular: things that actually use the "globus+extended VOMS" mapping approach via LCAS+LCMAPS map users + roles by either VOMS role or user DN in a site configurable way (generally, YAIM configures them to map via VOMS role first into a pool account with a group determined by the VOMS role, and then to fail down to mapping by DN to whatever the gridmapfile contains). Things that don't use LCMAPs do their own thing (DPM, for example, doesn't care about mapping people to unix groups or roles, because internally it records the actual DN as the username and the VOMS role as the "group" in the DPM namespace; gridftp, on the other hand, does do role mapping the LCMAPS way, so there's glue to join these together when gridftp is used). Sam > Thanks > > Henry > > -- > Dr. Henry Nebrensky [log in to unmask] > http://people.brunel.ac.uk/~eesrjjn > "The opossum is a very sophisticated animal. > It doesn't even get up until 5 or 6 p.m."