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? > [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 steved.
