Re: [PATCH v2] nfs: don't attempt auth methods that require upcall unless we know that gssd is running

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 24 Jan 2014 10:02:38 -0700
Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote:

> 
> 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.
> 

I'm not happy with the layering violations either. In this case the
problem is not serious -- just a spurious error message, but these sorts
of error messages tend to drive admins mad and cause them to call their
support vendors. Having to run gssd just to get rid of an error message
seems rather lame.

I guess the only semi-clean way to clean up the layering violation is
to somehow pass a "user intent" flag down to the lower layers. Then if
gssd isn't running, we'd just suppress the warning message. That's an
awful lot of code churn though, since the place where the log messages
occur is currently a long way away from the place where we actually
know what the intent was.

-- 
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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux