Gsi pool account mapping

1

Hi EOS community,

I have some trouble since a long time configuring the CMS with GSI authentication where some users have their DN can be mapped to their account and the others, when they have a proxy with voms attributes, have to be mapped to an CMS pool account.

For example, I have :

# grep sec.prot /etc/xrd.cf.mgm|grep gsi
sec.protocol gsi -crl:0 -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -gridmap:/etc/grid-security/grid-mapfile -d:0 -gmapopt:2 -vomsat:1 -moninfo:1
sec.protbind * only gsi sss unix

# eos vid ls|grep voms
voms:"/cms:":gid => gridcms
voms:"/cms:":uid => cmspool
voms:"/cms:lcgadmin":uid => cmss
voms:"/cms:production":uid => cmsp

[root@lyoeosmgm1 ~]# eos vid ls|grep gsi
gsi:"<pwd>":gid => root
gsi:"<pwd>":uid => root

I have tried some things in the /etc/grid-security/grid-mapfile, like :

"/O=GRID-FR/C=FR/O=CNRS/OU=IPNL/CN=Denis Pugnere" pugnere
"/*" nobody

With this, when I copy a file to my EOS instance with a valid proxy in the CMS VO, I can’t be mapped to the cmspool account :

$ voms-proxy-init --voms cms
Enter GRID pass phrase for this identity:
Contacting voms2.cern.ch:15002 [/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch] "cms"...
Remote VOMS server contacted succesfully.

When I copy a file, I have user access restricted - unauthorized identity used :

$ date ; xrdcp -f file:///etc/hosts root://lyoeosmgm1.in2p3.fr//eos/lyoeos.in2p3.fr/scratch/$(uuidgen)
Tue Nov 17 15:23:41 CET 2020
[0B/0B][100%][==================================================][0B/s]
Run: [ERROR] Server responded with an error: [3010] Unable to give access - user access restricted - unauthorized identity used ; Permission denied (destination)

The logs in the MGM (4.8.27), show :

201117 15:23:41 41000 XrootdXeq: pugnere.54899:428@lyoui1 pub IPv4 login as pugnere
201117 15:23:41 time=1605623021.700325 func=stat                     level=ERROR logid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx unit=mgm@lyoeosmgm1.in2p3.fr:1094 tid=00007f92f8bfd700 source=Stat:83                        tident=<single-exec> sec=gsi   uid=50001 gid=50000 name=pugnere geo="" user access restricted - unauthorized identity vid.uid=50001, vid.gid=50000, vid.host="lyoui1.in2p3.fr", vid.tident="pugnere.54899:428@lyoui1" for path="/eos/lyoeos.in2p3.fr/scratch/53f53330-66ed-4f20-9cda-68d3cf3a934c" user@domain="cmss@in2p3.fr"
201117 15:23:41 time=1605623021.700393 func=Emsg                     level=ERROR logid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx unit=mgm@lyoeosmgm1.in2p3.fr:1094 tid=00007f92f8bfd700 source=XrdMgmOfs:1186                 tident=<single-exec> sec=      uid=0 gid=0 name= geo="" Unable to give access - user access restricted - unauthorized identity used ; Permission denied
201117 15:23:41 time=1605623021.701546 func=IdMap                    level=INFO  logid=static.............................. unit=mgm@lyoeosmgm1.in2p3.fr:1094 tid=00007f92f8bfd700 source=Mapping:993                    tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=gsi sec.name="pugnere" sec.host="lyoui1.in2p3.fr" sec.vorg="cms" sec.grps="/cms" sec.role="lcgadmin" sec.info="/O=GRID-FR/C=FR/O=CNRS/OU=IPNL/CN=Denis Pugnere" sec.app="" sec.tident="pugnere.54899:428@lyoui1" vid.uid=50001 vid.gid=50000
201117 15:23:41 time=1605623021.701606 func=open                     level=ERROR logid=7e059f0a-28e0-11eb-b3de-7845c4fc35a5 unit=mgm@lyoeosmgm1.in2p3.fr:1094 tid=00007f92f8bfd700 source=XrdMgmOfsFile:393              tident=pugnere.54899:428@lyoui1 sec=gsi   uid=50001 gid=50000 name=pugnere geo="" user access restricted - unauthorized identity vid.uid=50001, vid.gid=50000, vid.host="lyoui1.in2p3.fr", vid.tident="pugnere.54899:428@lyoui1" for path="/eos/lyoeos.in2p3.fr/scratch/53f53330-66ed-4f20-9cda-68d3cf3a934c" user@domain="cmss@in2p3.fr"
201117 15:23:41 time=1605623021.701629 func=Emsg                     level=ERROR logid=7e059f0a-28e0-11eb-b3de-7845c4fc35a5 unit=mgm@lyoeosmgm1.in2p3.fr:1094 tid=00007f92f8bfd700 source=XrdMgmOfsFile:3175             tident=pugnere.54899:428@lyoui1 sec=gsi   uid=50001 gid=50000 name=pugnere geo="" Unable to give access - user access restricted - unauthorized identity used ; Permission denied
201117 15:23:41 41000 XrootdXeq: pugnere.54899:428@lyoui1 disc 0:00:00

$ eos root://lyoeosmgm1.in2p3.fr whoami
error: errc=3010 msg="[ERROR] Error response: Permission denied" (errc=3010) (Unknown error 3010)

Does the catchup :

"/*" nobody

is needed in the /etc/grid-security/grid-mapfile file ?

My primary goal is the make CMS grid accounts working, and if possible, also with someindividual GSI DN mapped to local accounts.

I must have missed something…
Thanks for your help,
Denis

2

Well, With the help of @barbet, thanks JM, we manage to find the problem and have a solution, I had :

[root@lyoeosmgm1 ~]# eos access ls
#
# ....................................................................................
# Allowd Users ...
# ....................................................................................
[ 01 ] pugnere

in my configuration, which has the effect that only this user can connect to this instance,

So I had to unallow the user :

eos access unallow user pugnere

Now, eos access ls command doesn’t show the user and the mapping to voms accounts are working .

But, when I restart the EOS instance, this allowed user is still came back there, the only occurrence found in my configuration is :

[root@lyoeosmgm1 ~]# eos config dump|grep 2059
global:/config/lyoeos.in2p3.fr/mgm#AllowedUsers => 2059:

But I don’t know how to unable this.

3

Hi Denis,

What version of eos are you running? Are you using the configuration in QDB or still the one stored in the file?
I tried your sequence of commands on my instance and the user is removed from the configuration. If you are still using the configuration saved in the local file then you can edit that file and remove the line which is of interest.

Cheers,
Elvin

4

Hi Elvin, thanks for your attention

[root@lyoeosmgm1 ~]# eos version
EOS_INSTANCE=lyoeos.in2p3.fr
EOS_SERVER_VERSION=4.8.27 EOS_SERVER_RELEASE=1
EOS_CLIENT_VERSION=4.8.27 EOS_CLIENT_RELEASE=1

My config is supposed to be in QDB :

[root@lyoeosmgm1 ~]# grep -E "mgmofs.nslib|mgmofs.cfgtype" /etc/xrd.cf.mgm
# mgmofs.cfgtype file
mgmofs.cfgtype quarkdb
# mgmofs.nslib /usr/lib64/libEosNsInMemory.so
mgmofs.nslib /usr/lib64/libEosNsQuarkdb.so
5

Hi Denis,

Hmm … this is strange. Can you please send me the output of the following commands?

eos access ls
eos access allow user pugnere
eos access ls
eos config dump | grep Allowed
eos access unallow user pugnere
eos access ls
eos config dump | grep Allowed
redis-cli -p 7777 hgetall eos-config:default | grep -i -A 1 Allowed

Thanks,
Elvin

6

Here is the result :

[root@lyoeosmgm1 ~]# eos access ls
[root@lyoeosmgm1 ~]# eos access allow user pugnere
success: allow 'pugnere'
[root@lyoeosmgm1 ~]# eos access ls
# ....................................................................................
# Allowd Users ...
# ....................................................................................
[ 01 ] pugnere
[root@lyoeosmgm1 ~]# eos config dump | grep Allowed
global:/config/lyoeos.in2p3.fr/mgm#AllowedUsers => 2059:
global:/config/lyoeos.in2p3.fr/mgm/#AllowedUsers => 2059:
[root@lyoeosmgm1 ~]# eos access unallow user pugnere
success: unallow 'pugnere'
[root@lyoeosmgm1 ~]# eos access ls
[root@lyoeosmgm1 ~]# eos config dump | grep Allowed
global:/config/lyoeos.in2p3.fr/mgm#AllowedUsers => 2059:

[root@lyoeosqdb1 ~]# redis-cli -p 7777 hgetall eos-config:default | grep -i -A 1 Allowed
global:/config/lyoeos.in2p3.fr/mgm#AllowedUsers
2059:

Denis

7

Hi Denis,

Ok, so now it’s clear where this is coming from. There is an artifact in the config that leads to this behavior. You can remove it by doing this:

redis-cli -p 7777 hdel eos-config:default "global:/config/eosdev/mgm#AllowedUsers"

Let me know if now things are fine.
Cheers,
Elvin

8

Thanks Elvin, It’s gone !

[root@lyoeosqdb1 ~]# redis-cli -p 7777 hdel eos-config:default "global:/config/lyoeos.in2p3.fr/mgm#AllowedUsers"
(integer) 1
[root@lyoeosqdb1 ~]# redis-cli -p 7777 hgetall eos-config:default | grep -i -A 1 Allowed

[root@lyoeosmgm1 ~]# systemctl restart eos@*
[root@lyoeosmgm1 ~]# eos access ls

This problem is now solved !

Now, about the need of

"/*" nobody

In the /etc/grid-security/grid-mapfile, to make the voms mapping matching the attributes, I don’t know why I need this.

Denis

9

Hi Denis,

We don’t have such an entry in our grid-map files. I guess what you want to achieve with this is that anyone not in the grid-map file is mapped to nobody. I don’t think you need this as anyone not in the gridmap file will be denied access anyway.

Cheers,
Elvin

10

Hi Elvin,

This is not exactly the case, as I want that any CMS grid users who use VOMS (with or without roles) except the local ones I have in my grid-mapfile to be mapped to theses 3 accounts :

  • to the cmspool account (for voms:"/cms:":uid => cmspool)
  • to the cmss account (for voms:"/cms:lcgadmin":uid => cmss)
  • to the cmsp account (for voms:"/cms:production":uid => cmsp)

So without "/*" nobody in the grid-mapfile, all gsi,unix access are mapped to nobody (uid=99). This is fuzzing me.

Cheers,
Denis

11

Hi Denis,

After a bit of experimenting I can explain what happens in this case. So without the "/*" nobody entry in the grid-map file when a user with a certificate/proxy comes at the MGM and if he’s not found in the other entries of the grid-map file then he will get an error. This is based on the principle that if you use a grid-map then any user accessing must be present there or matched to an entry. The error you get form the gsi library is the following:

201120 14:55:03 30078 cryptossl_X509::CertType: certificate has 2 extensions
201120 14:55:03 30078 cryptossl_X509::CertType: certificate has 11 extensions
201120 14:55:03 30078 secgsi_XrdOucGMap::dn2user: no valid match found for DN '/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=esindril/CN=706330/CN=Elvin Alin Sindrilaru'
201120 14:55:03 30078 secgsi_Authenticate: ERROR: user mapping required, but lookup failed - failure
201120 14:55:03 30078 XrootdXeq: User authentication failed;
201120 14:55:03 30078 XrootdXeq: esindril.1376:405@esdss000 pub IP64 login as esindril

Now, if you come with a certificate and your DN is in the grid-map file then you will get mapped to that identity - this is the simple case. If your DN is not in the grid-map file then you will go to the catch all directive "/*" nobody so this user will get mapped to nobody. This is the result of the mapping done in the gsi library.

At this point, the code enters the EOS part where you have defined the vid mapping. The information extracted by the gsi library also contains now the VOMS information. That information is used to overwrite the username if there is a match given the client’s certificate voms attributes and the vid mapping that you defined. In this way a client not in the grid-map file but with VOMS attributes matching what you specified in the vid mapping will get mapped to whatever is specified in the mapping.

Hope this explains it all!
Cheers,
Elvin

12

Hi Elvin,

Thank you very much for your explanation. This is what I want, so it is ok for me.
I don’t know if for the other sites it is working like this but our firsts test with @barbet in a test instance, the catchall "/*" nobody was not needed to match the voms attributes of the proxy when the DN of the user isn’t in the grid-mapfile.
So I was wondering if it was a miss-configuration from me or not.

Cheers,
Denis