lkml.org 
[lkml]   [2011]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Don't hang user processes if Kerberos ticket for nfs4 mount expires
    On Wed, 16 Nov 2011 20:31:19 -0500
    Jeff Layton <jlayton@redhat.com> wrote:

    > On Wed, 16 Nov 2011 18:44:34 -0500
    > Jim Rees <rees@umich.edu> wrote:
    >
    > > Jeff Layton wrote:
    > >
    > > Uhhh, no...EKEYEXPIRED was never passed to userland. The patchset that
    > > added EKEYEXPIRED returns in this codepath also added the code to make
    > > it hang.
    > >
    > > This not a bug, or at least it's intentional behavior. When a krb5
    > > ticket expires, we *want* the process to hang. Otherwise, people with
    > > long running jobs will often find that their jobs error out
    > > inexplicably when their ticket expires.
    > >
    > > Who decided that? This seems completely wrong to me. If my credentials
    > > expire, I want to get permission denied, not a client hang. In 20 years of
    > > using authenticated file systems I never once wished my process had hung
    > > when my ticket expired.
    > >
    >
    > I proposed it, we discussed it on the list, and Trond and Steve
    > committed the patches necessary to make it happen. This was back in
    > late 2009/early 2010 though, so my memory is a bit fuzzy...
    >
    > > Why should this be any different from any other failure condition? If you
    > > try to open a file that doesn't exist, do you want your process to hang
    > > instead of getting ENOENT, just in case the file magically appears at some
    > > point in the future?
    > >
    >
    > That's different. Not renewing your credentials is often a temporary
    > situation. Kerberos is different than other authentication methods in
    > that you get a ticket only for a period of time, so expired credentials
    > are not a situation that's common with other authentication methods.
    >
    > > This seems a recipe for disaster. Suppose I have a cron job that fires once
    > > a minute, and all those jobs hang waiting for a ticket. I come to work in
    > > the morning and discover I've got 10,000 hung processes. Or not, because my
    > > computer has crashed from resource exhaustion.
    >
    > The previous situation was also a recipe for disaster, and was often
    > cited as a primary reason why people didn't want to deploy kerberized
    > NFS. Having everything fall down and go boom when your ticket expires
    > is not desirable either.
    >
    > I suppose we'll have to agree to disagree on this point. That said, I'm
    > open to sane suggestions however that don't regress the behavior for
    > those users who need to be able to cope with expired tickets.
    >

    Note too that the gssd code distinguishes between an expired TGT and a
    non-existent credcache. The latter will give you the error you desire
    here. So one possibility is just to remove the credcache from /tmp in
    this situation.

    Another possibility might be a new option to rpc.gssd that allows the
    user to select the error that it passes back to the kernel on an
    expired ticket.

    --
    Jeff Layton <jlayton@redhat.com>


    \
     
     \ /
      Last update: 2011-11-17 02:39    [W:0.034 / U:61.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site