Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Jason Keltz" <jas@eecs.yorku.ca>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: ksu problem with sec=krb5 and nfs
Date:   Mon, 24 May 2021 10:48:46 -0400
Message-ID: <0D324C0D-A00C-4A44-9814-2D717F830DF9@redhat.com>
In-Reply-To: <dd51738b-b2c2-2dcf-68b1-e78c66d08b28@eecs.yorku.ca>
References: <abbd93ac-4a68-a471-fbb4-a9baf05b89c9@eecs.yorku.ca>
 <7714ABF4-E9CD-424B-BF7F-6F1B91F58C2B@redhat.com>
 <dd51738b-b2c2-2dcf-68b1-e78c66d08b28@eecs.yorku.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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