All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simo Sorce <simo@redhat.com>
To: Trond Myklebust <trondmy@gmail.com>
Cc: Steve Dickson <SteveD@redhat.com>,
	Andy Adamson <William.Adamson@netapp.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH Version 2 0/3] GSSD: Use gss-ctx keys and gsskeyd to sync Kerberos credentials and kernel gss_contexts.
Date: Fri, 22 Nov 2013 16:39:31 -0500	[thread overview]
Message-ID: <1385156371.22025.5.camel@willson.li.ssimo.org> (raw)
In-Reply-To: <3ABF556D-FA65-4A9E-9880-5AA5ADF80F55@gmail.com>

On Fri, 2013-11-22 at 16:28 -0500, Trond Myklebust wrote:
> On Nov 22, 2013, at 14:11, Simo Sorce <simo@redhat.com> wrote:
> 
> > On Thu, 2013-11-21 at 08:37 -0500, Steve Dickson wrote:
> >> 
> >> On 20/11/13 15:49, Simo Sorce wrote:
> >>>> I think Solution 3: [nfslog/nfslogout interfaces invoked from PAM or
> >>>>> other login system facility] is a good way to go.  Note that a PAM
> >>>>> based solution where in the PAM would get us most of the way towards
> >>>>> providing users with a way to login and logout of NFS kerberized
> >>>>> shares.
> >>>>> 
> >>>>> Comments on an NFS PAM that will destroy GSS context for a UID upon
> >>>>> logout?
> >>> I prefer 3 too, let it to the login system (whether PAM based or other)
> >>> to determine when it is time to destroy credentials, that's the only
> >>> component that have a chance of guessing right.
> 
> Really? How do you deal with backgrounded tasks?

for  background tasks you still need to keep your kerberos credentials
around somehow, if you are doing that then the kernel will be able to
get a new session key if needed.
If you instruct your system to destroy everything then background tasks
will fail. In any case it needs to be a user space decision, the kernel
can't guess.

> >>> Of course you could also provide a user utility to force a purge.
> >>> 
> >> +1 for me on this options as well... 
> >> 
> >> But how is it known when somebody logs out? Is that PAM-able as well?
> > 
> > I would say "login process" more than pam, but the basic idea is the
> > same, a user space program that knows when the user is logging out for
> > good and is privileged enough to go an tell the kernel to nuke creds.
> 
> What’s such a process going to use as an indicator that the user is “logging out for good”?

If you do logout from a graphical login manager that's a pretty good
indication I would say. Whether that will work for all use cases is
debatable of course, I am sure cases can be found where that will not
the right option.

On a system where it is too difficult to properly assess automatically
when a user is logged out for good the only option is to disable any
automatism and let the user call a cmdline tool.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


  reply	other threads:[~2013-11-22 21:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 14:22 [PATCH Version 2 0/3] GSSD: Use gss-ctx keys and gsskeyd to sync Kerberos credentials and kernel gss_contexts andros
2013-10-22 14:22 ` [PATCH Version 2 1/3] GSSD add cc_name to upcall andros
2013-10-22 15:07   ` Simo Sorce
2013-10-22 14:22 ` [PATCH Version 2 2/3] WIP: Add gsskeyd andros
2013-10-23 14:30   ` Steve Dickson
2013-10-23 14:40     ` Weston Andros Adamson
2013-10-23 15:02       ` Adamson, Andy
2013-10-22 14:22 ` [PATCH Version 2 3/3] ANDROS: update gsskeyd to use new /run/user/UID/krb5cc/tgt cache file andros
2013-10-22 15:02 ` [PATCH Version 2 0/3] GSSD: Use gss-ctx keys and gsskeyd to sync Kerberos credentials and kernel gss_contexts Simo Sorce
2013-10-22 15:32   ` Adamson, Andy
2013-10-22 16:09     ` Simo Sorce
2013-10-22 17:00       ` Adamson, Andy
2013-10-22 17:25         ` Simo Sorce
2013-11-20 20:35           ` Adamson, Andy
2013-11-20 20:49             ` Simo Sorce
2013-11-20 21:21               ` Adamson, Andy
2013-11-20 21:24                 ` Adamson, Andy
2013-11-22 19:09                 ` Simo Sorce
2013-11-22 20:44                   ` Adamson, Andy
2013-11-21 13:37               ` Steve Dickson
2013-11-22 19:11                 ` Simo Sorce
2013-11-22 21:28                   ` Trond Myklebust
2013-11-22 21:39                     ` Simo Sorce [this message]
2013-10-22 15:46   ` Weston Andros Adamson
2013-10-22 16:11     ` Simo Sorce
2013-10-22 16:14       ` Weston Andros Adamson
2013-10-22 16:39         ` Adamson, Andy

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=1385156371.22025.5.camel@willson.li.ssimo.org \
    --to=simo@redhat.com \
    --cc=SteveD@redhat.com \
    --cc=William.Adamson@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@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.