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?
We had many complaints from users of krb5 mounts where long-running
jobs would routinely fail when the ticket expired.
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:
http://permalink.gmane.org/gmane.linux.nfsv4/11019
With EKEYEXPIRED, we'd want RPCs to hang indefinitely until the tickets
were renewed. 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.
This patch makes it sound like you're wanting to revert that behavior.
Is that the case? 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?
--
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
