 |
 |
There's three options: 0. Match against the first FQAN; ignore the rest. 1. Match against the last FQN; ignore the rest. (Old default) 2. Copy all information. (New default; didn't exist in v0.3.0) 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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/1006#issuecomment-503397300 ######################################################################## 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