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;
MIME-Version: 1.0
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>
In-Reply-To: <CAN-5tyEjwEm7TohcHGPtub=DAM0=J9K0mN+epaNQu+E3+OB_FQ@mail.gmail.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Tue, 10 Dec 2019 19:44:53 -0500
Message-ID: <CAN-5tyH_6tyxk2_eY4=K1E2tDB88usDt5ipg-wX+0AwPb_FY_A@mail.gmail.com>
Subject: Re: gssd question/patch
To:     Steve Dickson <SteveD@redhat.com>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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?

Any luck reproducing? I asked Jorge to try and he sees the same problem.

>
> >
> > steved.
> >