On Wed, Aug 31, 2016 at 3:10 PM, Matt Garman <matthew.garman@xxxxxxxxx> wrote: > On Wed, Aug 31, 2016 at 1:40 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> The lifetime (expressed in seconds) of the gss context is determined >> to be the end lifetime of the service ticket - time now. > > Based on a simple experiment, I don't think this is true (or I'm > mis-understanding your explanation). What I did is log into a host > that uses NFSv4 sec=krb5p home directories. klist shows the service > ticket for nfs as not expiring until October 27, 2016 (I have all > ticket lifetimes in Kerberos configured for 70 days). > > Now, I do a "kdestroy" and make a note of the time. I then run a > simple loop like this: > > # while [ 1 ] ; do date ; ls ; sleep 1m ; done > > Twice now I've done this experiment on two different hosts. After > almost exactly an hour, I start getting "Permission denied". > > But from your description above, I would expect that I shouldn't see > "Permission denied" until the end of October, right? I should have asked for what distro/nfs-utils are you using? In the RHEL/Fedora nfs-utils distros, lifetime of the context is gotten from gss_inquire_context() call from the gss krb5 api. In krb5_gss_inquire_context() in krb5 source code in src/lib/gssapi/krb5/inq_context.c it's set to what I have set before. A server can choose to expire the context at any time by returning gss context error and force the client to create the new security context. What server are you going against? A network trace would be helpful to check to see if the server is returning such error. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
