There were 2 things wrong with auth flavour ordering:

- Mountd used to advertise AUTH_NULL as the first flavour on
  the list, which means that it prefers AUTH_NULL to anything
  else (as per RFC 2623 section 2.7).
- Mount.nfs used to scan the returned list in reverse order,
  and stopping at the first AUTH_NULL or AUTH_SYS encountered.
  If a server advertises (AUTH_SYS, AUTH_NULL), it will by
  default choose AUTH_NULL and have degraded access.

I've fixed mount.nfs to scan from the beginning. For mountd,
it does not advertise AUTH_NULL anymore. This is necessary
to avoid backward compatibility issue. If AUTH_NULL appears
in the list, either the new or the old client will choose
that over AUTH_SYS.

Tested the server/client combination against the previous
versions, as well as Solaris and FreeBSD.

Signed-off-by: bc Wong <bcwong@cisco.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

1 files changed, 8 insertions, 1 deletions

diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index 63d5ce1..8137f7f 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -342,7 +342,14 @@ mount_mnt_3_svc(struct svc_req *rqstp, dirpath *path, mountres3 *res)
 #define AUTH_GSS_KRB5 390003
 #define AUTH_GSS_KRB5I 390004
 #define AUTH_GSS_KRB5P 390005
-	static int	flavors[] = { AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I, AUTH_GSS_KRB5P};
+	static int	flavors[] = { AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I, AUTH_GSS_KRB5P};
+	/*
+	 * We should advertise the preferred flavours first. (See RFC 2623
+	 * section 2.7.) AUTH_UNIX is arbitrarily ranked over the GSS's.
+	 * AUTH_NULL is dropped from the list to avoid backward compatibility
+	 * issue with older Linux clients, who inspect the list in reversed
+	 * order.
+	 */
 	struct nfs_fh_len *fh;
 
 	xlog(D_CALL, "MNT3(%s) called", *path);