All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olga Kornievskaia <aglo@umich.edu>
To: Matt Garman <matthew.garman@gmail.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: gss context cache and nfsv4
Date: Wed, 31 Aug 2016 15:41:26 -0400	[thread overview]
Message-ID: <CAN-5tyFhPkrgvcrJ_2n20sFkczaVrf1YC5WR9_b5W31E+a7thw@mail.gmail.com> (raw)
In-Reply-To: <CAJvUf-BwEKes-C-D3xxXyYEV9bTFpQ6JTn1iEwknQ4FwKhxQmw@mail.gmail.com>

On Wed, Aug 31, 2016 at 3:10 PM, Matt Garman <matthew.garman@gmail.com> wrote:
> On Wed, Aug 31, 2016 at 1:40 PM, Olga Kornievskaia <aglo@umich.edu> 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.

  reply	other threads:[~2016-08-31 19:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 16:36 gss context cache and nfsv4 Matt Garman
2016-08-31 18:40 ` Olga Kornievskaia
2016-08-31 19:10   ` Matt Garman
2016-08-31 19:41     ` Olga Kornievskaia [this message]
2016-11-02 14:03       ` Matt Garman
2016-11-02 16:54         ` Olga Kornievskaia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN-5tyFhPkrgvcrJ_2n20sFkczaVrf1YC5WR9_b5W31E+a7thw@mail.gmail.com \
    --to=aglo@umich.edu \
    --cc=linux-nfs@vger.kernel.org \
    --cc=matthew.garman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.