I don’t really understand the unix/krb5 permissions :
$ xrdcp -v toto root://np02ss18.cern.ch//eos/users/dpugnere/toto
[0B/0B][100%][==================================================][0B/s]
Run: [ERROR] Server responded with an error: [3010] Unable to open file /eos/users/dpugnere/toto; Operation not permitted
[root@np02ss18 mgm]# eos vid ls -a
auth=krb5
auth=sss
[root@np02ss18 mgm]# eos vid ls -U
krb5:"<pwd>":uid => root
sss:"<pwd>":uid => root
tident:"sss@np02ss18.cern.ch":uid => root
unix:"<pwd>":uid => nobody
I suspect I should use the mapping command :
eos -b vid set map -unix
or eos -b vid set map -krb5
But I don’t know how. I’d be happy to read any suggestion / comment.
Best regards,
Denis
Probably the kerberos authentication is not enforce because some things are missing. To know if the user is authenticated, run this : eos whoami
Do you have a file /etc/krb5.keytab containing the key of the principal you use to authenticate against (host/np02ss18@CERN.CH), you can check by running klist -k /etc/krb5.keytab.
Your user should also have a valid kerberos ticket created by kinit.
Kerberos configuration is not necessary on the FSTs, only on the MGM.
So the whoami command from the client gives you a nobody identity, despite your valid kerberos ticket.
To understand what is going on on client side, you can enable the debugging of xrootd security : XrdSecDEBUG=1 eos whoami
You should get something like :
sec_Client: protocol request for host eos-contingency.acme.com token='&P=krb5,eosstorage@ACME.COM&P=sss,0.13:/etc/eos.keytab&P=unix'
sec_PM: Loaded krb5 protocol object from libXrdSeckrb5.so
sec_PM: Using krb5 protocol, args='eosstorage@ACME.COM'
Seckrb5: getCredentials
Seckrb5: context lock
Seckrb5: context locked
Seckrb5: FILE:/tmp/krb5cc_61928_kc8pWeEwrZ
Seckrb5: init context
Seckrb5: cc set default name
Seckrb5: Returned 512 bytes of creds; p=eosstorage@ACME.COM
Virtual Identity: uid=61928 (61928,99) gid=40507 (99,61895,65422,29431,41068,54068,43590,63804,40507,22605,50003,504,507) [authz:krb5] host=s-fdfasf87v.acme.com
with authz:krb5.
To debug what is going on on the mgm side, you can look at the logs (/var/log/eos/mgm/xrdlog.mgm), if the verbosity is high enough.
Of course, the kerberos principal dpugnere@CERN.CH should be entitled to get ticket against host/np02ss19@CERN.CH principal. This can be tested this way with MIT kerberos : kvno host/np02ss18@CERN.CH
[dpugnere@np02ss19:~/]$ XrdSecDEBUG=1 eos whoami
sec_Client: protocol request for host np02ss18.cern.ch token='&P=krb5,host/np02ss18@CERN.CH&P=sss,0.13:/etc/eos.keytab&P=unix'
sec_PM: Loaded krb5 protocol object from libXrdSeckrb5.so
sec_PM: Using krb5 protocol, args='host/np02ss18@CERN.CH'
Seckrb5: getCredentials
Seckrb5: FILE:/tmp/krb5cc_28122_r7StfgaEnt
Seckrb5: init context
Seckrb5: cc set default name
Seckrb5: cc default
Seckrb5: context lock
Seckrb5: context locked
Seckrb5: get_krbCreds: unable to get creds; Server not found in Kerberos database
sec_Client: protocol request for host np02ss18.cern.ch token='&P=sss,0.13:/etc/eos.keytab&P=unix'
sec_PM: Loaded sss protocol object from libXrdSecsss.so
sec_PM: Using sss protocol, args='0.13:/etc/eos.keytab'
sec_sss: Init_Client: Unable to determine keytab location.
sec_PM: Loaded unix protocol object from libXrdSecunix.so
sec_PM: Using unix protocol, args=''
Virtual Identity: uid=99 (99) gid=99 (99) [authz:unix] host=np02ss19.cern.ch
I see there Seckrb5: get_krbCreds: unable to get creds; Server not found in Kerberos database
[dpugnere@np02ss19:~/]$ kvno host/np02ss18@CERN.CH
kvno: Server not found in Kerberos database while getting credentials for host/np02ss18@CERN.CH
[dpugnere@np02ss19:~/]$ kvno host/np02ss18.cern.ch@CERN.CH
host/np02ss18.cern.ch@CERN.CH: kvno = 3
[dpugnere@np02ss19:~/]$ kvno np02ss18
np02ss18@CERN.CH: kvno = 3
and :
[root@np02ss19 ~]# cern-get-keytab
Current keytab file (/etc/krb5.keytab) is valid.
Use --force to reinitialize.
OK, so for some reason linked to the kerberos infrastructure at CERN (of which I don’t know anything), you cannot use host/np02ss18@CERN.CH as principal to authenticate against for your eos instance (the kvno test fails; the principal might have been disabled, or the system configuration doesn’t specify a KDC server for it). But the two others are good candidates it seems, since the kvno action succeeds for them.
You might already have deduced that you can change the line in the xrd.cf.mgm file by specific another principal, e.g. :
sec.protocol krb5 host/np02ss18.cern.ch@CERN.CH
You need to restart the mgm after this change, and you should be able to authenticate using kerberos, hopefully…