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