Kerberos ksu not working with NFSv4 mount sec=krb5

[Jason Keltz]

Hi.

I'm unable to get ksu working wth krb5 NFSv4, and can't quite figure out 
why.

I am logged into a RHEL7 system as a user "jas" (uid 1004) with working 
Kerberos (Samba AD implementation).

I want to switch from user jas to user tdb (uid 1011) using ksu.

I set up a .k5login file in tdb account containing jas at AD.EECS.YORKU.CA

If tdb home directory is mounted with sec=sys, as jas I can "ksu tdb" 
and it works every time.

If tdb home directory is mounted with sec=krb5, ksu wants me to enter  a 
password.

(Note that as jas I can still cat ~tdb/.k5login).

KRB5CCNAME is FILE:/tmp/krb5cc_1004

rpc.gssd -vvv returns:

 > handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 ' 
(nfs/clnt0)
 > krb5_not_machine_creds: uid 1011 tgtname (null)
 > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE 
(Unspecified GSS failure.  Minor code may provide more information) - No 
Kerberos credentials available: Credentials cache permissions incorrect 
(filename: /tmp/krb5cc_1004)
 > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
in /tmp
 > CC '/tmp/krb5cc_1004' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5cc_1004' owned by 1004, not 1011
 > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with 
preferred realm 'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
 > CC '/tmp/krb5cc_0' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5cc_0' owned by 0, not 1011
 > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
in /run/user/%U
 > Error doing scandir on directory '/run/user/1011': No such file or 
directory
 > doing error downcall
 >
 > handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 ' 
(nfs/clnt0)
 > krb5_not_machine_creds: uid 1011 tgtname (null)
 > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE 
(Unspecified GSS failure.  Minor code may provide more information) - No 
Kerberos credentials available: Credentials cache permissions incorrect 
(filename: /tmp/krb5cc_1004)
 > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
in /tmp
 > CC '/tmp/krb5cc_1004' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5cc_1004' owned by 1004, not 1011
 > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with 
preferred realm 'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
 > CC '/tmp/krb5cc_0' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5cc_0' owned by 0, not 1011
 > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
in /run/user/%U
 > Error doing scandir on directory '/run/user/1011': No such file or 
directory
 > doing error downcall

If I actually enter the password then /tmp/krb5cc_1011 shows up, and 
everything works.

 > handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 ' 
(nfs/clnt0)
 > krb5_not_machine_creds: uid 1011 tgtname (null)
 > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE 
(Unspecified GSS failure.  Minor code may provide more information) - No 
Kerberos credentials available: Credentials cache permissions incorrect 
(filename: /tmp/krb5cc_1004)
 > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
in /tmp
 > CC '/tmp/krb5cc_1004' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5cc_1004' owned by 1004, not 1011
 > CC '/tmp/krb5cc_1011.9bpz551G' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC 'FILE:/tmp/krb5cc_1011.9bpz551G'(tdb at AD.EECS.YORKU.CA) passed all 
checks and has mtime of 1621645808
 > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with 
preferred realm 'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
 > CC '/tmp/krb5cc_0' being considered, with preferred realm 
'AD.EECS.YORKU.CA'
 > CC '/tmp/krb5cc_0' owned by 0, not 1011
 > using FILE:/tmp/krb5cc_1011.9bpz551G as credentials cache for client 
with uid 1011 for server sea.eecs.yorku.ca
 > using gss_krb5_ccache_name to select krb5 ccache 
FILE:/tmp/krb5cc_1011.9bpz551G
 > creating tcp client for server sea.eecs.yorku.ca
 > DEBUG: port already set to 2049
 > creating context with server nfs at sea.eecs.yorku.ca
 > DEBUG: serialize_krb5_ctx: lucid version!
 > prepare_krb5_rfc4121_buffer: protocol 1
 > prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
 > doing downcall: lifetime_rec=36000 acceptor=nfs at sea.eecs.yorku.ca

Is ksu just verifying that I'm a valid kerberos user, and that a switch 
can be made to the new uid, then changing the uid with setuid only, in 
which case Kerberos NFS won't work,  or, is it supposed to import the 
ticket for destination user as well?

If I enter the password when prompted, I can write files as the 
destination user tdb, but I don't want to enter a password.

As a side note, if I set an ACL on the source users /tmp/krb5cc_1004 
file to allow the destination user (1011) to read it (which I know is 
incorrect), then the ksu "works" successfully, but of course the 
destination user can't write into the home directory anyway since the 
principal isn't present.  It's not clear if this is a ksu issue, or 
rpc.gssd and if this is fixable on my end or not.

Jason.