xrootd-voms / vomsxrd: Argument parsing issue

[olifre]

(I'm not sure whether this is the correct place for vomsxrd issues, but since the issue tracker on https://github.com/xrootd/vomsxrd is off, I presume so)

The following configuration line:

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|grpopt=21|vos=atlas,ops,dteam,wlcg|grps=/atlas,/ops,/dteam,/wlcg

maps all VOs and groups correctly (it seems), but the following configuration line:

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|vos=atlas,ops,dteam,wlcg|grps=/atlas,/ops,/dteam,/wlcg|grpopt=21

ignores any but the very first VO / group.

I don't see an apparent bug in the argument parsing code, sadly, even running xrootd with -d does not turn on the debug output in the plugin (and setting dbg comes too late).

Let me know if there's any way to turn on the debug output for the argument parsing or any other information I could provide.

[abh3]

I think the issue here is that the gropt values are reverse. It is sel*10+which and in the case you present the grpopt should be '12' not '21'. This is the reason you get odd behavior depending on where the gropt is placed and the "grps" option modifies the gropt value but works only if it is correct. Depending on the release you may have seen a warning in the log about this. I agree, this is confusing. However, specify gropt=12 to see if this solves your problem. In any case. All that said, it looks like gropt needs to be specified ahead of the grps in any case. I will fix this in R5.

[olifre]

@abh3 Thanks, indeed I got the grpopt numbers flipped! Sorry for that.

However, I can also reproduce the problem with "12":

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|vos=atlas,ops,dteam,wlcg|grps=/atlas,/ops,/dteam,/wlcg|grpopt=12

(i.e. authentication for any but the first VO fails) vs.

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|grpopt=12|vos=atlas,ops,dteam,wlcg|grps=/atlas,/ops,/dteam,/wlcg

which works fine.

Interestingly, it also fails if I completely remove grpopt. My understanding of the code / documentation was that 12 is the setting which will automatically be used if grps is set.
I'm using xrootd 4.12.1 (with xrootd-voms 4.12.1).

[bbockelm]

Just my $0.02: I have no idea what option 12 is without having the docs open in a separate tab.

Can we have an alias for something vaguely human-readable?

[abh3]

Sure, this is historical. No reason to use english language as opposed to numeric language :-)

…

On Mon, 18 May 2020, Brian P Bockelman wrote: Just my $0.02: I have no idea what option `12` is without having the docs open in a separate tab. Can we have an alias for something vaguely human-readable? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1196 (comment)

[abh3]

So, exactly which voms are you using? That is, where did the voms in /usr/lib64/libXrdSecgsiVOMS.so come from? I can't build it using 4.12.1 as there seems to be a configuration issue in that release relative to the voms submodule. So, hat make me wonder.

[olifre]

That is, where did the voms in /usr/lib64/libXrdSecgsiVOMS.so come from?

Interesting! I wanted to say, from the xrootd-voms package of course, but here's what I get:

# rpm -qf /usr/lib64/libXrdSecgsiVOMS-4.so 
xrootd-libs-4.12.1-1.el7.x86_64
xrootd-voms-4.12.1-1.el7.x86_64

I installed xrootd-voms last, so this must be the package which won the fight. Both packages come from:
https://xrootd.slac.stanford.edu/binaries/stable/slc/7/x86_64/
i.e. the RPMs from the XRootD stable repos.

I checked md5sums to confirm: The md5sums of all libraries match:

72846faa5bd9dfb1d6d032a69b3573c0  xrootd-libs/usr/lib64/libXrdSecgsiVOMS-4.so
72846faa5bd9dfb1d6d032a69b3573c0  xrootd-voms/usr/lib64/libXrdSecgsiVOMS-4.so
72846faa5bd9dfb1d6d032a69b3573c0  /usr/lib64/libXrdSecgsiVOMS-4.so

So I guess we have a second issue here: The release RPMs package libXrdSecgsiVOMS-4.so twice (but luckily, it's the exact same file).

[abh3]

@olifre OK, I have a fixed VOMS (at least I think it's fixed). However, the fixes are in the R5 branch. That library will work just fine for R4. The trick is how do I get that to you? I can compile it and send it to you (if you give me a platform spec) or you can compile it from git head (on a platform that has vomsapi and voms-dev installed). If you do the latter simply rename libXrdSecgsiVOMS-5.so to libXrdSecgsiVOMS-4.so and either replace the one you have or explicitly specify its location. The R4 VOMS library has a number of problems. So, I would just go with the EPEL version not ours. Anyway, I would appreciate if you test it and hopefully it will meet your expectations.

[olifre]

@abh3: This is bascially efe81d6 , right? I see this also adds an additional, more human-oriented syntax, many thanks for that!

I can compile it and send it to you (if you give me a platform spec) or you can compile it from git head (on a platform that has vomsapi and voms-dev installed).

That would be much appreciated. I tried to compile XRootD 5 on CentOS 7.8 x86_64 (which our nodes run), but cmake is already too old, so I would have to compile that (or otherwise bind that in) first. Seems CentOS 7 is already getting old as a development platform.
So if you could send me a version for CentOS 7 x86_64 (7.8, but that should not matter) that would be much appreciated. I'll then finally take our test node into operation to try this out (maybe not today, but surely this week).

The R4 VOMS library has a number of problems. So, I would just go with the EPEL version not ours.

We're using voms from EPEL, so that fits ;-).

[olifre]

@abh3
We have now updated to 4.12.2 which of course also provides the "test binary", since it contains efe81d6 ;-).

And I have good news!

Now, both:

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdVoms.so -vomsfunparms:certfmt=raw|grpopt=useall|vos=atlas,ops,dteam,wlcg|grps=/atlas,/atlas/de,/ops,/dteam,/wlcg|dbg

and

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdVoms.so -vomsfunparms:certfmt=raw|vos=atlas,ops,dteam,wlcg|grps=/atlas,/atlas/de,/ops,/dteam,/wlcg|dbg|grpopt=useall

work fine, also dbg works as expected. Note I am also making good use of the new grpopt=useall syntax and the nicely shortened name libXrdVoms.so.

Thanks for all this, this issue can be closed :-).