EOS authentication system (unix and krb5)

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

Here is the /eos/users directory

[root@np02ss18 mgm]# eos ls -lr /eos/users
drwxrwx--+   1 dpugnere np-comp             0 Apr  3 18:37 dpugnere
drwxrwxr-+   1 epennacc np-comp             0 Apr  3 17:11 epennacc
drwxrwxr-+   1 np02copy np-comp             0 Apr  3 17:11 np02copy
drwxrwxr-+   1 np02daq  np-comp             0 Apr  3 17:11 np02daq
drwxrwxr-+   1 np02onlp np-comp             0 Apr  3 17:11 np02onlp
drwxrwxr-+   1 tviant   np-comp             0 Apr  3 17:11 tviant

when I set the /eos/users/dpugnere permission to 777, the file is owned by nobody

Here is my configuration :

[root@np02ss18 mgm]# grep -E "sec.(protocol|protbind)" /etc/xrd.cf.mgm
sec.protocol unix
sec.protocol sss -c /etc/eos.keytab -s /etc/eos.keytab
sec.protocol krb5 host/np02ss18@CERN.CH
sec.protbind localhost.localdomain unix sss
sec.protbind localhost unix sss
sec.protbind * only krb5 sss unix

And the eos command shows :

[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

Hi 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.

For what I know, you shouldn’t need any map set.

Hi Franck,

on the MGM (as root) :
[root@np02ss18 mgm]# eos whoami
Virtual Identity: uid=0 (2,99,3,0) gid=0 (99,4,0) [authz:sss] sudo* host=localhost
[root@np02ss18 mgm] # klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 np02ss18$@CERN.CH
3 np02ss18$@CERN.CH
3 np02ss18$@CERN.CH
3 NP02SS18$@CERN.CH
3 NP02SS18$@CERN.CH
3 NP02SS18$@CERN.CH
3 host/np02ss18.cern.ch@CERN.CH
3 host/np02ss18.cern.ch@CERN.CH
3 host/np02ss18.cern.ch@CERN.CH
3 host/np02ss18@CERN.CH
3 host/np02ss18@CERN.CH
3 host/np02ss18@CERN.CH

On the client (as root) :
[root@np02ss19 ~]# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 np02ss19$@CERN.CH
3 np02ss19$@CERN.CH
3 np02ss19$@CERN.CH
3 NP02SS19$@CERN.CH
3 NP02SS19$@CERN.CH
3 NP02SS19$@CERN.CH
3 host/np02ss19.cern.ch@CERN.CH
3 host/np02ss19.cern.ch@CERN.CH
3 host/np02ss19.cern.ch@CERN.CH
3 host/np02ss19@CERN.CH
3 host/np02ss19@CERN.CH
3 host/np02ss19@CERN.CH

On the client (as the user) :
[dpugnere@np02ss19:~/]$ export EOS_MGM_URL=“root://np02ss18.cern.ch”
[dpugnere@np02ss19:~/]$ eos whoami
Virtual Identity: uid=99 (99) gid=99 (99) [authz:unix] host=np02ss19.cern.ch
[dpugnere@np02ss19:~/]$ klist
Ticket cache: FILE:/tmp/krb5cc_28122_hWTQbQxrNN
Default principal: dpugnere@CERN.CH

Valid starting       Expires              Service principal
04/04/2018 10:48:32  04/05/2018 11:48:25  krbtgt/CERN.CH@CERN.CH
	renew until 04/09/2018 10:48:25

Denis

I realize that the krb5 configuration is only present in the /etc/xrd.cf.mgm MGM node, but not on the FSTs.

On the FSTs :
[root@np02ss04 ~]# grep -E “sec.(protocol|protbind)” /etc/xrd.cf.fst
sec.protocol unix
sec.protocol sss -c /etc/eos.keytab -s /etc/eos.keytab
sec.protbind * only unix sss

Should I have this ?
sec.protocol unix
sec.protocol sss -c /etc/eos.keytab -s /etc/eos.keytab
sec.protocol krb5 host/$HOSTNAME@CERN.CH
sec.protbind localhost.localdomain unix sss
sec.protbind localhost unix sss
sec.protbind * only krb5 sss unix

Denis

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

example:

$ kvno eosstorage
eosstorage@ACME.COM: kvno = 3
1 Like

Thanks a lot Franck,

[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.

Denis

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…

You got it !

[dpugnere@np02ss19:~/]$ XrdSecDEBUG=1 eos whoami
sec_Client: protocol request for host np02ss18.cern.ch token='&P=krb5,host/np02ss18.cern.ch@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@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: Returned 2100 bytes of creds; p=host/np02ss18.cern.ch@CERN.CH
Virtual Identity: uid=28122 (28122,99) gid=1395 (1395,99) [authz:krb5] host=np02ss19.cern.ch

You save my week ! thank you so much Franck.
Best regards,
Denis

1 Like