krb5_cc_get_principal: Credentials cache I/O operation failed

[ahmet2mir]

Hello,

When cache get initialized under same user using same Keyring (Persistent) cache.primary_principal raises Error: krb5_cc_get_principal: Credentials cache I/O operation failed

To reproduce, start 2 shells on the same host.

On Shell 1 and 2, run

shell_1_2> require 'rkerberos'
shell_1_2> keytab = "/etc/my.keytab"
shell_1_2> principal = "myprincipal@mydomain.com"
shell_1_2> krb5 = Kerberos::Krb5.new
shell_1_2> ccache = Kerberos::Krb5::CredentialsCache.new

Now on Shell 1 run

shell_1> krb5.get_init_creds_keytab principal, keytab, nil, ccache
shell_1> ccache.primary_principal

Run klist

$ klist
Ticket cache: KEYRING:persistent:123:123
Default principal: myprincipal@mydomain.com

Valid starting       Expires              Service principal
02/10/2023 08:07:44  02/11/2023 08:07:44  HTTP/node.mydomain.com@mydomain.com
02/10/2023 08:07:44  02/11/2023 08:07:44  krbtgt/mydomain.com@mydomain.com

It works as expected.

On Shell 2 run also

shell_2> krb5.get_init_creds_keytab principal, keytab, nil, ccache
shell_2> ccache.primary_principal

It works too, klist returns a new refreshed ticket.

$ klist
Ticket cache: KEYRING:persistent:123:123
Default principal: myprincipal@mydomain.com

Valid starting       Expires              Service principal
02/10/2023 08:07:58  02/11/2023 08:07:58  HTTP/node.mydomain.com@mydomain.com
02/10/2023 08:07:58  02/11/2023 08:07:58  krbtgt/mydomain.com@mydomain.com

But go back to Shell 1, and just retrieve prinipal from cache

shell_1> ccache.primary_principal
irb(main):011:0> ccache.primary_principal
Traceback (most recent call last):
        3: from console.rb:3:in `<main>'
        2: from (irb):11
        1: from (irb):11:in `primary_principal'
Kerberos::Krb5::Exception (krb5_cc_get_principal: Credentials cache I/O operation failed)
irb(main):012:0> 

Issue raised here https://github.com/domcleal/rkerberos/blob/master/ext/rkerberos/ccache.c#L171

So for now, we just don't use primary_principal attribute and everything goes well.

Any idea for the why ? Is it expected ? Or something on MIT code ?

[ahmet2mir]

Regarding this issue #10, this is not thread safe (in our case 2 threads init the cache and this kind of issue could happen, and nothing todo right ?