On Wed, 16 Nov 2011 20:31:19 -0500 Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Wed, 16 Nov 2011 18:44:34 -0500 > Jim Rees <rees@xxxxxxxxx> 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@xxxxxxxxxx> -- 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
