Kerberos ksu not working with NFSv4 mount sec=krb5

[Benjamin Kaduk]

On Sat, May 22, 2021 at 02:22:08PM -0400, Jason Keltz wrote:
> 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)

This seems to say that setuid() succeeded, and now rpc.gssd is looking
around in /tmp/ for a credentials cache that has tickets that can
authenticate to NFS for the current user.  It seems that it's looking at
the krb5cc file from jas, that is owned by jas, and seeing that the
permissions don't match the (now-)expected tdb user as owner.


>  > 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?

[it looks like my understanding of what ksu does with credential caches is
incorrect, so what I originally wrote here was incorrect and thus I deleted
it.  The man page discussion for -z, -Z, and maybe -k may be of interest.]

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

It might be worth experimenting with not setting KRB5CCNAME, and
investigating whether the pam configuration is the immediate trigger for
the password prompt (I don't expect it to be coming from ksu itself), but I
think this is not likely to be fixable easily.  rpc.gssd seems to
both be doing what it's intended to do, that just happens to not interact
very well with what ksu does.

-Ben