Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: gssd question/patch
To:     Olga Kornievskaia <aglo@umich.edu>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>
References: <CAN-5tyHJg4C5j72_CrCJhZ8hyzDe71Q9zw1USgmyxePg+3juZw@mail.gmail.com>
 <8c69eee5-9dc1-2a14-1bd2-cf812bdb39a4@RedHat.com>
 <CAN-5tyH-m=n2m8-qWbV-4iYJUhx4yMFz_uWUWAzYGArN5yxJaw@mail.gmail.com>
 <47f12fef-bf43-62d8-adda-303e3e551f36@RedHat.com>
 <CAN-5tyEjwEm7TohcHGPtub=DAM0=J9K0mN+epaNQu+E3+OB_FQ@mail.gmail.com>
 <CAN-5tyH_6tyxk2_eY4=K1E2tDB88usDt5ipg-wX+0AwPb_FY_A@mail.gmail.com>
From:   Steve Dickson <SteveD@RedHat.com>
Message-ID: <583a32ec-15ae-1646-fe68-246371e8e978@RedHat.com>
Date:   Wed, 11 Dec 2019 11:29:58 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CAN-5tyH_6tyxk2_eY4=K1E2tDB88usDt5ipg-wX+0AwPb_FY_A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


On 12/10/19 7:44 PM, Olga Kornievskaia wrote:
> On Mon, Dec 9, 2019 at 3:20 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>>
>> On Mon, Dec 9, 2019 at 3:06 PM Steve Dickson <SteveD@redhat.com> wrote:
>>>
>>>
>>>
>>> On 12/9/19 11:49 AM, Olga Kornievskaia wrote:
>>>> Hi Steve,
>>>>
>>>> On Mon, Dec 9, 2019 at 11:10 AM Steve Dickson <SteveD@redhat.com> wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> On 12/6/19 1:29 PM, Olga Kornievskaia wrote:
>>>>>> Hi Steve,
>>>>>>
>>>>>> Question: Is this an interesting failure scenario (bug) that should be
>>>>>> fixed: client did a mount which acquired gss creds and stored in the
>>>>>> credential cache. Then say it umounts at some point. Then for some
>>>>>> reason the Kerberos cache is deleted (rm -f /tmp/krb5cc*). Now client
>>>>>> mounts again. This currently fails. Because gssd uses internal cache
>>>>>> to store creds lifetimes and thinks that tgt is still valid but then
>>>>>> trying to acquire a service ticket it fails (since there is no tgt).
>>>>> I'm unable reproduce the scenario....
>>>>>
>>>>> (as root) mount -o sec=krb5 server:/home/tmp /mnt/tmp
>>>>> (as kuser) kinit kuser
>>>>> (as kuser) touch /mnt/tmp/foobar
>>>>> (as root) umount /mnt/tmp/
>>>>> (as root) rm -f /tmp/krb5cc*
>>>>> (as root) mount -o sec=krb5 server:/home/tmp /mnt/tmp
>>>>> (as kuser) touch /mnt/tmp/foobar # which succeeds
>>>>>
>>>>> Where am I going wrong?
>>>>
>>>> Not sure. Can you please post gssd verbose output?
>>>>
>>>> Set up. Client kernel somewhat recent though the latest, but in
>>>> reality doesn't matter i think
>>>> gssd from nfs-utils commit 5a004c161ff6c671f73a92d818a502264367a896
>>>> "gssd: daemonize earlier"
>>>>
>>>> [aglo@localhost nfs-utils]$ sudo mount -o vers=4.1,sec=krb5
>>>> 192.168.1.72:/nfsshare /mnt
>>>> [aglo@localhost nfs-utils]$ touch /mnt/kerberos
>>> Is there a kinit before this?
>>
>> yep.
>>
>>>> [aglo@localhost nfs-utils]$ sudo umount /mnt
>>>> [aglo@localhost nfs-utils]$ sudo rm -fr /tmp/krb5cc*
>>>> [aglo@localhost nfs-utils]$ sudo mount -o vers=4.1,sec=krb5
>>>> 192.168.1.72:/nfsshare /mnt
>>>> mount.nfs: access denied by server while mounting 192.168.1.72:/nfsshare
>>>>
>>>> Here's the gssd error output: If you look at 1st "INFO: Credentials in
>>>> CC .... are good until..." is a lie as there isn't even a file there.
>>> Here is what I'm seeing:
>>>    https://paste.centos.org/view/9473f4a3
>>
>> Well, can't see anything there (well I'm seeing the same double INFO
>> which according to the code pass would not try to get the tgt and it
>> should fail).
>>
>> I'm not using gss_proxy. Are  you?
Yes I am... I'll try turning it off.. 

> 
> Any luck reproducing? I asked Jorge to try and he sees the same problem.
Not yet... but I'm still trying... 

steved.

> 
>>
>>>
>>> steved.
>>>
>