On Jan 24, 2014, at 5:46, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> Currently, if the server lists krb5 as an allowed auth method, but gssd isn't
> running, you'll get the infamous "AUTH_GSS upcall failed" message, even if
> you didn't request sec=krb5.
>
> This is because nfs4_find_root_sec() establishes a default list of auth
> methods to try when the admin didn't supply one, and that list contains
> AUTH_GSS methods first. Skip those methods if gssd isn't running since
> they won't succeed anyway.
>
> Cc: Weston Andros Adamson <dros@xxxxxxxxxx>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> fs/nfs/nfs4proc.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 15052b8..937a05a 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -2900,6 +2900,14 @@ static int nfs4_find_root_sec(struct nfs_server *server, struct nfs_fh *fhandle,
> } else {
> /* no flavors specified by user, try default list */
> for (i = 0; i < ARRAY_SIZE(flav_array); i++) {
> + /*
> + * Don't attempt to upcall with the default list
> + * unless we know that gssd is running.
> + */
> + if (flav_array[i] > RPC_AUTH_MAXFLAVOR &&
> + !gssd_running(server->nfs_client->cl_net))
> + continue;
Big effing NACK.
This is exactly the kind of layering violation creep whereby the NFS layer ends up tracking more and more of the implementation details in the RPC authentication which made me hesitant about allowing gssd_running to be exported in the first place.
--
Trond Myklebust
Linux NFS client maintainer
--
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
