There's three options:
The group information indeed can be multi-valued (space separated). So if you have /atlas
and /atlas/usatlas
as groups in the proxy, then this would match against either an authfile rule for g /atlas
or g /atlas/usatlas
.
That said, I don't see how role-based matching could be useful here; there's no enforcement that the role comes from a given VO. How do you know it was an atlas
production user and not an ops
production user?
For group-based matching, you have a pretty good idea that the group named /atlas
comes from the ATLAS VO. This is just a naming convention, however; the CMS VO can also have a group named /atlas
but it doesn't. To the best of my knowledge, only OSG goes the length of patching libvomsapi
to enforce this convention (only the VO named atlas
can have a group name beginning with /atlas
.
With respect to having a very old version in the WLCG repo: I'm not the right person for that. I can only point at what OSG has available (which isn't affected by the issues described above).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1