ksu problem with sec=krb5 and nfs

ksu problem with sec=krb5 and nfs

[Jason Keltz]

Hi.

I'm unable to get ksu working wth krb5 NFSv4.  I think I can understand 
why it doesn't work, but I'm looking for help finding a solution.

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

I want to switch to a user that is tdb (uid 1011) using ksu.

I set up a .k5login file in tdb account containing jas@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, I get permission denied 
unless I enter a password.

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

KRB5CCNAME is FILE:/tmp/krb5cc_1004 (I can't use the keyring because the 
Kerberos server in Samba doesn't support this on RHEL7).

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@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@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@sea.eecs.yorku.ca

Of course I can exit and the ksu session, and restart it, and it doesn't 
ask for a password because the ticket is in the right place now.

rpc.gssd wouldn't see KRB5CCNAME variable as its a running daemon, but 
it seems to do the right thing looking for the right file in /tmp.

Can someone help me understand the issue, and whether there is a solution?

Jason.

Re: ksu problem with sec=krb5 and nfs

[Benjamin Coddington]

On 22 May 2021, at 10:47, Jason Keltz wrote:

> Can someone help me understand the issue, and whether there is a solution?

Don't you want ksu to write its target cache to /tmp/krb5cc_1011 so rpc.gssd
can find it?  Why isn't that happening?

Ben

Re: ksu problem with sec=krb5 and nfs

[Jason Keltz]

Hi Benjamin,

That's exactly it - I definately want ksu to be writing that exact 
file.  Any idea why it isn't, and why it matters if the home directory 
is using sec=krb5 or not?

Jason.

On 5/24/2021 7:30 AM, Benjamin Coddington wrote:
> On 22 May 2021, at 10:47, Jason Keltz wrote:
>
>> Can someone help me understand the issue, and whether there is a solution?
> Don't you want ksu to write its target cache to /tmp/krb5cc_1011 so rpc.gssd
> can find it?  Why isn't that happening?
>
> Ben
>
>

Re: ksu problem with sec=krb5 and nfs

[Benjamin Coddington]

On 24 May 2021, at 10:44, Jason Keltz wrote:

> Hi Benjamin,
>
> That's exactly it - I definately want ksu to be writing that exact 
> file.  Any idea why it isn't, and why it matters if the home 
> directory is using sec=krb5 or not?

Because if you're mounting with sec=krb5, then the kernel's going to 
upcall to rpc.gssd, which is going to try to find the credential cache 
to establish a context with the NFS server.  None of that has to happen 
with sec=sys.

As far as where ksu puts the target cred cache - I don't know the 
details there.  Dig into the ksu source, or docs.. maybe you need to set 
the krb5cc default cred cache.

Ben