On Jun 28, 2012, at 11:43 AM, Jeff Layton wrote: > On Wed, 27 Jun 2012 16:05:34 -0400 > andros@xxxxxxxxxx wrote: > >> From: Andy Adamson <andros@xxxxxxxxxx> >> >> Without this patch attempting to access a Kerberos mount with expired or no >> credentials resulted in the NFS client hanging while retrying to refresh creds >> for ever. >> >> I tested NFSv3/v4/v4.1 sec=krb5 mounts. With expired or non-existent user >> Kerberos credentials, trying to ls the mountpoint, or cd into the mountpoint >> resulted in three failed upcalls to gssd (due to tk_cred_retry being set to 2) >> then the 'Operation not permitted' message is returned to the user. >> >> I think this patch should go into the stable kernel. >> >> Andy Adamson (1): >> SUNRPC handle EKEYEXPIRED in call_refreshresult >> >> fs/nfs/nfs4proc.c | 2 -- >> net/sunrpc/clnt.c | 4 ++++ >> 2 files changed, 4 insertions(+), 2 deletions(-) >> > > Wait...is this really the behavior you want here? Yes. Just having the client hang with no indication to the user is wrong. > > We had many complaints from users of krb5 mounts where long-running > jobs would routinely fail when the ticket expired. That is a Kerberos ticket management issue, not an NFS kernel client issue. You have long-running jobs, then kinit -l, run krenew, or use a keytab with a cron job, or use some other credential management software package. > The compromise behavior that we worked out at that time was to treat an > expired credcache differently from a "no credcache" situation. gssd would > return EKEYEXPIRED if the credcache existed but was expired, and > EACCES otherwise. The kernel would then treat those errors > differently: In both cases, EPERM is the correct response from the Linux NFS client, as the user has no permissions to do anything in the file system. > > http://permalink.gmane.org/gmane.linux.nfsv4/11019 > > With EKEYEXPIRED, we'd want RPCs to hang indefinitely until the tickets > were renewed. Sounds like a good DOS attack. Consider V4.1 and a multi-user machine. If a users credentials expire during a heavy I/O run - that user could be using all of the session slots, and no other user could make progress while the RPCs call rpc_delay and retry indefinitely... > With EACCES, the call would return an error. The idea > there is that the user would kdestroy if he needed to unwedge his krb5 > mount. Exactly how is the user supposed to know to kdestroy? All they see is a hung mount. > > This patch makes it sound like you're wanting to revert that behavior. > Is that the case? Yes. > If so, what about people trying to run long-running > tasks on a kerberized mount? Are they just SOL if their ticket isn't > renewed in time? Yes - as with _any_ resource, you need to plan ahead. As I said above, the administrator in such a situation needs to setup krenew or the equivalent. -->Andy > > -- > 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
