below top level mounting NFS3 authentication patch

At our faculty we use Linux (Debian) clients and Solaris 9/10 file servers. We use the automounter on the Linux clients to access home directories with krb5. The servers export the home directories on the level above the user home directories.
Kernel 2.6.18 allows this behavior, kernels later then 2.6.23 do not. The underlying cause for the problem is the interpretation of the wording in RFC 2623, sec 2.3.2. This allows fsinfo with UNIX authentication on the root of the export. But the automounter mounts below the root of the export/share and the Solaris server (justly) requires full, i.e. krb5, authentication. Thus the mount fails, which makes the automounter useless in our environment. The client should try both authentications and use the first one that succeeds.
The nfs_proc_get_root subroutine in nfs3proc already does
this, but...
the call to the sget routine earlier in the routine nfs_get_sb causes a fsinfo call that always uses UNIX authentication. Which causes the mount to fail.

The solution i came up with is simple. Transplant the way get_root handles this to fsinfo. This is implemented in the patch to 2.6.24-rc4 in the attachment.

The are probably better solutions. For example by collapsing the two calls to get_root and fsinfo. But all i needed was something that made things work for me and did not ruin something for anybody.

It would be nice if this patch found its way into the distribution...

Ed Keizer
IT group tel: +31 20 5987804
Faculty of Sciences fax: +31 20 5987653
Vrije Universiteit e-mail: keie-vHs5IaWfoDhmR6Xm/[email protected]
De Boelelaan 1081A, 1081 HV Amsterdam, The Netherlands

fs/dcache.c +0 -0

fs/nfs/nfs3proc.c +17 -2

index 4cdc236..1215d42 100644
@@ -687,7 +687,7 @@ nfs3_proc_statfs(struct nfs_server *server, struct nfs_fh *fhandle,
 }
 
 static int
-nfs3_proc_fsinfo(struct nfs_server *server, struct nfs_fh *fhandle,
+do_proc_fsinfo(struct rpc_clnt *client, struct nfs_fh *fhandle,
 		 struct nfs_fsinfo *info)
 {
 	struct rpc_message msg = {

@@ -699,11 +699,26 @@ nfs3_proc_fsinfo(struct nfs_server *server, struct nfs_fh *fhandle,
 
 	dprintk("NFS call  fsinfo\n");
 	nfs_fattr_init(info->fattr);
-	status = rpc_call_sync(server->nfs_client->cl_rpcclient, &msg, 0);
+	status = rpc_call_sync(client, &msg, 0);
 	dprintk("NFS reply fsinfo: %d\n", status);
 	return status;
 }
 
+/*
+ * Bare-bones access to fsinfo: this is for nfs_get_root/nfs_get_sb via nfs_create_server
+ */
+static int
+nfs3_proc_fsinfo(struct nfs_server *server, struct nfs_fh *fhandle,
+		   struct nfs_fsinfo *info)
+{
+	int	status;
+
+	status = do_proc_fsinfo(server->client, fhandle, info);
+	if (status && server->nfs_client->cl_rpcclient != server->client)
+		status = do_proc_fsinfo(server->nfs_client->cl_rpcclient, fhandle, info);
+	return status;
+}
+
 static int
 nfs3_proc_pathconf(struct nfs_server *server, struct nfs_fh *fhandle,
 		   struct nfs_pathconf *info)

Quoted 22 lines · EG Keizer

At our faculty we use Linux (Debian) clients and Solaris 9/10 file servers. We use the automounter on the Linux clients to access home directories with krb5. The servers export the home directories on the level above the user home directories.
Kernel 2.6.18 allows this behavior, kernels later then 2.6.23 do not. The underlying cause for the problem is the interpretation of the wording in RFC 2623, sec 2.3.2. This allows fsinfo with UNIX authentication on the root of the export. But the automounter mounts below the root of the export/share and the Solaris server (justly) requires full, i.e. krb5, authentication. Thus the mount fails, which makes the automounter useless in our environment. The client should try both authentications and use the first one that succeeds.
The nfs_proc_get_root subroutine in nfs3proc already does
this, but...
the call to the sget routine earlier in the routine nfs_get_sb causes a fsinfo call that always uses UNIX authentication. Which causes the mount to fail.

The solution i came up with is simple. Transplant the way get_root handles this to fsinfo. This is implemented in the patch to 2.6.24-rc4 in the attachment.

Quoted 5 lines

The are probably better solutions. For example by collapsing the two calls to get_root and fsinfo. But all i needed was something that made things work for me and did not ruin something for anybody.

It would be nice if this patch found its way into the distribution...

Seems fine to me. Doesn't v2 need the same treatment as v3 here, though?

--b.

Quoted 54 lines

Ed Keizer
IT group tel: +31 20 5987804
Faculty of Sciences fax: +31 20 5987653
Vrije Universiteit e-mail: keie-vHs5IaWfoDhmR6Xm/[email protected]
De Boelelaan 1081A, 1081 HV Amsterdam, The Netherlands

fs/dcache.c +0 -0

fs/nfs/nfs3proc.c +17 -2

index 4cdc236..1215d42 100644
@@ -687,7 +687,7 @@ nfs3_proc_statfs(struct nfs_server *server, struct nfs_fh *fhandle,
 }
 
 static int
-nfs3_proc_fsinfo(struct nfs_server *server, struct nfs_fh *fhandle,
+do_proc_fsinfo(struct rpc_clnt *client, struct nfs_fh *fhandle,
 		 struct nfs_fsinfo *info)
 {
 	struct rpc_message msg = {

@@ -699,11 +699,26 @@ nfs3_proc_fsinfo(struct nfs_server *server, struct nfs_fh *fhandle,
 
 	dprintk("NFS call  fsinfo\n");
 	nfs_fattr_init(info->fattr);
-	status = rpc_call_sync(server->nfs_client->cl_rpcclient, &msg, 0);
+	status = rpc_call_sync(client, &msg, 0);
 	dprintk("NFS reply fsinfo: %d\n", status);
 	return status;
 }
 
+/*
+ * Bare-bones access to fsinfo: this is for nfs_get_root/nfs_get_sb via nfs_create_server
+ */
+static int
+nfs3_proc_fsinfo(struct nfs_server *server, struct nfs_fh *fhandle,
+		   struct nfs_fsinfo *info)
+{
+	int	status;
+
+	status = do_proc_fsinfo(server->client, fhandle, info);
+	if (status && server->nfs_client->cl_rpcclient != server->client)
+		status = do_proc_fsinfo(server->nfs_client->cl_rpcclient, fhandle, info);
+	return status;
+}
+
 static int
 nfs3_proc_pathconf(struct nfs_server *server, struct nfs_fh *fhandle,
 		   struct nfs_pathconf *info)