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 [email protected]
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'([email protected]) 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 [email protected]
> 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 [email protected]
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.
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
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
>
>
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