On 12/10/19 7:44 PM, Olga Kornievskaia wrote: > On Mon, Dec 9, 2019 at 3:20 PM Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> >> On Mon, Dec 9, 2019 at 3:06 PM Steve Dickson <SteveD@xxxxxxxxxx> 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@xxxxxxxxxx> 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. >>> >