CERN Accelerating science

EOS and GSI auth


We are trying to set up GSI auth on an MGM node without using gridmap files.

sec.protparm gsi -vomsfun:/usr/lib64/ -vomsfunparms:certfmt=pem
sec.protocol gsi -dlgpxy:request -exppxy:=creds -crl:require -d:1 -cert:/etc/grid-security/xrootd/hostcert.pem -key:/etc/grid-security/xrootd/hostkey.pem -gmapopt:null
sec.protbind gsi

I have set up the following mappings

voms:"/dteam/Role=NULL/Capability=NULL":gid => root
voms:"/dteam/Role=NULL/Capability=NULL":uid => root

but I get an " Operation not permitted" error when I try to xrdcp a file using my dteam voms proxy certificate. I mean I am still mapped to the “nobody” user

210702 13:38:23 time=1625229503.322152 func=Emsg level=ERROR logid=63be77e8-db32-11eb-bf2d-1c34da4b345c tid=00007f0fcc6f7700 source=XrdMgmOfsFile:3227 sec=gsi uid=99 gid=99 name=a0f3a615.0 geo="" Unable to open file /eos/antares/gsitest/libxrdceph.tar.gz; Operation not permitted

Do you know what should I do? Many thanks!.



Just to say, that I wasn’t extracting the VOMS attributes but now I do. Also the way I did
“vid set map -voms” was wrong (according to the documentation). Now I have

voms:"/dteam:":gid => root
voms:"/dteam:":uid => root

but I am still seen be EOS as “nobody”

210706 13:03:25 time=1625573005.181700 func=IdMap level=INFO logid=static… tid=00007fd3003d7700 source=Mapping:993 tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=gsi“a0f3a615.0”“” sec.vorg=“dteam” sec.grps="/dteam" sec.role=“NULL”"""" sec.tident="" vid.uid=99 vid.gid=99

210706 13:03:25 time=1625573005.182435 func=Emsg level=ERROR logid=2aceda36-de52-11eb-b9c9-1c34da4b345c tid=00007fd3003d7700 source=XrdMgmOfsFile:3227 sec=gsi uid=99 gid=99 name=a0f3a615.0 geo="" Unable to open file /eos/antares/gsitest/libxrdceph.tar.gz; Operation not permitted

Actually, this is what finally worked

vid set map -voms /dteam:NULL vuid:0 vgid:0

you may want to update the “eos vid” doc. The NULL string is needed after all in the -voms pattern


Hi George,

All this depends actually what and how the certificate attributes are extracted. You can figure out what was extracted by looking at the log line where each info is printed in the MGM log file. For example, in an instance with the following gsi config:

sec.protocol gsi -crl:0 -cert:/etc/grid-security/daemon/hostcert.pem -key:/etc/grid-security/daemon/hostkey.pem -gridmap:/etc/grid-security/grid-mapfile -d:1 -gmapopt:2 -vomsat:1 -moninfo:1

And my certificate VOMS extension looking like this:

=== VO cms extension information ===
VO        : cms
subject   : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=esindril/CN=706330/CN=Elvin Alin Sindrilaru
issuer    : /DC=ch/DC=cern/OU=computers/
attribute : /cms/Role=NULL/Capability=NULL
timeleft  : 11:47:16
uri       :

Having the following vid rule:

voms:"/cms:":gid => c3
voms:"/cms:":uid => eosarchi

The mapping works fine. You can see in the logs what info the gsi extracted from the certificate and then you can tweak the vid rule to match. In my particular case:

210709 08:57:23 time=1625777843.471083 func=IdMap                    level=INFO  logid=static.............................. tid=00007fab416ae700 source=Mapping:1003                   tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=gsi
="esindril""" sec.vorg="cms" sec.grps="/cms" sec.role="""/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=esindril/CN=706330/CN=Elvin Alin Sindrilaru""" sec.tident="esindril.2742:386@esdss000" vid.uid=58603 vid.gid=1028

Note the sec.role field is empty so the vid rule matches.