nfsd: permit unauthenticated stat of export root

From: J. Bruce Fields <[email protected]>

RFC 2623 section 2.3.2 permits the server to bypass gss authentication checks for certain operations that a client may perform when mounting. In the case of a client that doesn't have some form of credentials available to it on boot, this allows it to perform the mount unattended. (Presumably real file access won't be needed until a user with credentials logs in.)

Being slightly more lenient allows lots of old clients to access krb5-only exports, with the only loss being a small amount of information leaked about the root directory of the export.

This affects on v2 and v3; v4 still requires authentication for all access.

Signed-off-by J. Bruce Fields <[email protected]>

---
 fs/nfsd/nfs3proc.c        |    5 +++--
 fs/nfsd/nfsfh.c           |   30 ++++++++++++++++++++----------
 fs/nfsd/nfsproc.c         |    6 ++++--
 fs/nfsd/vfs.c             |    4 ++--
 include/linux/nfsd/nfsd.h |    3 ++-
 5 files changed, 31 insertions(+), 17 deletions(-)

I intend to submit this for 2.6.28

fs/nfsd/nfs3proc.c +1 -1

index 4d617ea..1419142 100644
@@ -530,7 +530,7 @@ nfsd3_proc_fsstat(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	dprintk("nfsd: FSSTAT(3)   %s\n",
 				SVCFH_fmt(&argp->fh));
 
-	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats);
+	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats, 0);
 	fh_put(&argp->fh);
 	RETURN_STATUS(nfserr);
 }

fs/nfsd/nfsfh.c +20 -10

index f45451e..7c6847e 100644
@@ -302,17 +302,27 @@ fh_verify(struct svc_rqst *rqstp, struct svc_fh *fhp, int type, int access)
 	if (error)
 		goto out;
 
-	if (!(access & NFSD_MAY_LOCK)) {
-		/*
-		 * pseudoflavor restrictions are not enforced on NLM,
-		 * which clients virtually always use auth_sys for,
-		 * even while using RPCSEC_GSS for NFS.
-		 */
-		error = check_nfsd_access(exp, rqstp);
-		if (error)
-			goto out;
-	}
+	/*
+	 * pseudoflavor restrictions are not enforced on NLM,
+	 * which clients virtually always use auth_sys for,
+	 * even while using RPCSEC_GSS for NFS.
+	 */
+	if (access & NFSD_MAY_LOCK)
+		goto skip_pseudoflavor_check;
+	/*
+	 * Clients may expect to be able to use auth_sys during mount,
+	 * even if they use gss for everything else; see section 2.3.2
+	 * of rfc 2623.
+	 */
+	if (access & NFSD_MAY_BYPASS_GSS_ON_ROOT
+			&& exp->ex_path.dentry == dentry)
+		goto skip_pseudoflavor_check;
+
+	error = check_nfsd_access(exp, rqstp);
+	if (error)
+		goto out;
 
+skip_pseudoflavor_check:
 	/* Finally, check access permissions. */
 	error = nfsd_permission(rqstp, exp, dentry, access);
 

fs/nfsd/nfsproc.c +4 -2

index 0766f95..5cffeca 100644
@@ -65,7 +65,8 @@ nfsd_proc_getattr(struct svc_rqst *rqstp, struct nfsd_fhandle  *argp,
 	dprintk("nfsd: GETATTR  %s\n", SVCFH_fmt(&argp->fh));
 
 	fh_copy(&resp->fh, &argp->fh);
-	nfserr = fh_verify(rqstp, &resp->fh, 0, NFSD_MAY_NOP);
+	nfserr = fh_verify(rqstp, &resp->fh, 0,
+			NFSD_MAY_NOP | NFSD_MAY_BYPASS_GSS_ON_ROOT);
 	return nfsd_return_attrs(nfserr, resp);
 }
 

@@ -521,7 +522,8 @@ nfsd_proc_statfs(struct svc_rqst * rqstp, struct nfsd_fhandle   *argp,
 
 	dprintk("nfsd: STATFS   %s\n", SVCFH_fmt(&argp->fh));
 
-	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats);
+	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats,
+			NFSD_MAY_BYPASS_GSS_ON_ROOT);
 	fh_put(&argp->fh);
 	return nfserr;
 }

fs/nfsd/vfs.c +2 -2

index 0f4481e..f51bdf6 100644
@@ -1872,9 +1872,9 @@ out:
  * N.B. After this call fhp needs an fh_put
  */
 __be32
-nfsd_statfs(struct svc_rqst *rqstp, struct svc_fh *fhp, struct kstatfs *stat)
+nfsd_statfs(struct svc_rqst *rqstp, struct svc_fh *fhp, struct kstatfs *stat, int access)
 {
-	__be32 err = fh_verify(rqstp, fhp, 0, NFSD_MAY_NOP);
+	__be32 err = fh_verify(rqstp, fhp, 0, NFSD_MAY_NOP | access);
 	if (!err && vfs_statfs(fhp->fh_dentry,stat))
 		err = nfserr_io;
 	return err;

include/linux/nfsd/nfsd.h +2 -1

index a2861d9..47bea82 100644
@@ -39,6 +39,7 @@
 #define NFSD_MAY_LOCK		32
 #define NFSD_MAY_OWNER_OVERRIDE	64
 #define NFSD_MAY_LOCAL_ACCESS	128 /* IRIX doing local access check on device special file*/
+#define NFSD_MAY_BYPASS_GSS_ON_ROOT 256
 
 #define NFSD_MAY_CREATE		(NFSD_MAY_EXEC|NFSD_MAY_WRITE)
 #define NFSD_MAY_REMOVE		(NFSD_MAY_EXEC|NFSD_MAY_WRITE|NFSD_MAY_TRUNC)

@@ -126,7 +127,7 @@ int		nfsd_truncate(struct svc_rqst *, struct svc_fh *,
 __be32		nfsd_readdir(struct svc_rqst *, struct svc_fh *,
 			     loff_t *, struct readdir_cd *, filldir_t);
 __be32		nfsd_statfs(struct svc_rqst *, struct svc_fh *,
-				struct kstatfs *);
+				struct kstatfs *, int access);
 
 int		nfsd_notify_change(struct inode *, struct iattr *);
 __be32		nfsd_permission(struct svc_rqst *, struct svc_export *,

Quoted 44 lines · J. Bruce Fields

From: J. Bruce Fields <[email protected]>

RFC 2623 section 2.3.2 permits the server to bypass gss authentication checks for certain operations that a client may perform when mounting. In the case of a client that doesn't have some form of credentials available to it on boot, this allows it to perform the mount unattended. (Presumably real file access won't be needed until a user with credentials logs in.)

Being slightly more lenient allows lots of old clients to access krb5-only exports, with the only loss being a small amount of information leaked about the root directory of the export.

This affects on v2 and v3; v4 still requires authentication for all access.

Signed-off-by J. Bruce Fields <[email protected]>

---
 fs/nfsd/nfs3proc.c        |    5 +++--
 fs/nfsd/nfsfh.c           |   30 ++++++++++++++++++++----------
 fs/nfsd/nfsproc.c         |    6 ++++--
 fs/nfsd/vfs.c             |    4 ++--
 include/linux/nfsd/nfsd.h |    3 ++-
 5 files changed, 31 insertions(+), 17 deletions(-)

I intend to submit this for 2.6.28

fs/nfsd/nfs3proc.c +2 -0

index 4d617ea..1419142 100644
@@ -530,7 +530,7 @@ nfsd3_proc_fsstat(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	dprintk("nfsd: FSSTAT(3)   %s\n",
 				SVCFH_fmt(&argp->fh));
 -	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats);
+	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats, 0);
 	fh_put(&argp->fh);
 	RETURN_STATUS(nfserr);
 }

@@ -558,7 +558,8 @@ nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	resp->f_maxfilesize = ~(u32) 0;
 	resp->f_properties = NFS3_FSF_DEFAULT;
 -	nfserr = fh_verify(rqstp, &argp->fh, 0, NFSD_MAY_NOP);
+	nfserr = fh_verify(rqstp, &argp->fh, 0,

fs/nfsd/nfs3proc.c nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle *argp,

Quoted 4 lines

fs/nfsd/nfs3proc.c +1 -0

+			NFSD_MAY_NOP | NFSD_MAY_BYPASS_GSS_ON_ROOT);
  	/* Check special features of the file system. May request
 	 * different read/write sizes for file systems known to have
 

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Quoted 46 lines · Peter Staubach

Quoted 44 lines · J. Bruce Fields

From: J. Bruce Fields <[email protected]>

RFC 2623 section 2.3.2 permits the server to bypass gss authentication checks for certain operations that a client may perform when mounting. In the case of a client that doesn't have some form of credentials available to it on boot, this allows it to perform the mount unattended. (Presumably real file access won't be needed until a user with credentials logs in.)

Being slightly more lenient allows lots of old clients to access krb5-only exports, with the only loss being a small amount of information leaked about the root directory of the export.

This affects on v2 and v3; v4 still requires authentication for all access.

Signed-off-by J. Bruce Fields <[email protected]>

---
 fs/nfsd/nfs3proc.c        |    5 +++--
 fs/nfsd/nfsfh.c           |   30 ++++++++++++++++++++----------
 fs/nfsd/nfsproc.c         |    6 ++++--
 fs/nfsd/vfs.c             |    4 ++--
 include/linux/nfsd/nfsd.h |    3 ++-
 5 files changed, 31 insertions(+), 17 deletions(-)

I intend to submit this for 2.6.28

fs/nfsd/nfs3proc.c +2 -0

index 4d617ea..1419142 100644
@@ -530,7 +530,7 @@ nfsd3_proc_fsstat(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	dprintk("nfsd: FSSTAT(3)   %s\n",
 				SVCFH_fmt(&argp->fh));
 -	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats);
+	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats, 0);
 	fh_put(&argp->fh);
 	RETURN_STATUS(nfserr);
 }

@@ -558,7 +558,8 @@ nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	resp->f_maxfilesize = ~(u32) 0;
 	resp->f_properties = NFS3_FSF_DEFAULT;
 -	nfserr = fh_verify(rqstp, &argp->fh, 0, NFSD_MAY_NOP);
+	nfserr = fh_verify(rqstp, &argp->fh, 0,

Quoted 9 lines

fs/nfsd/nfs3proc.c nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle *argp,

Quoted 5 lines

fs/nfsd/nfs3proc.c +1 -0

+			NFSD_MAY_NOP | NFSD_MAY_BYPASS_GSS_ON_ROOT);
  	/* Check special features of the file system. May request
 	 * different read/write sizes for file systems known to have
 

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

Quoted 57 lines · J. Bruce Fields

Quoted 45 lines · Peter Staubach

Quoted 43 lines · J. Bruce Fields

From: J. Bruce Fields <[email protected]>

RFC 2623 section 2.3.2 permits the server to bypass gss authentication checks for certain operations that a client may perform when mounting. In the case of a client that doesn't have some form of credentials available to it on boot, this allows it to perform the mount unattended. (Presumably real file access won't be needed until a user with credentials logs in.)

Being slightly more lenient allows lots of old clients to access krb5-only exports, with the only loss being a small amount of information leaked about the root directory of the export.

This affects on v2 and v3; v4 still requires authentication for all access.

Signed-off-by J. Bruce Fields <[email protected]>

---
 fs/nfsd/nfs3proc.c        |    5 +++--
 fs/nfsd/nfsfh.c           |   30 ++++++++++++++++++++----------
 fs/nfsd/nfsproc.c         |    6 ++++--
 fs/nfsd/vfs.c             |    4 ++--
 include/linux/nfsd/nfsd.h |    3 ++-
 5 files changed, 31 insertions(+), 17 deletions(-)

I intend to submit this for 2.6.28

fs/nfsd/nfs3proc.c +1 -0

index 4d617ea..1419142 100644
@@ -530,7 +530,7 @@ nfsd3_proc_fsstat(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	dprintk("nfsd: FSSTAT(3)   %s\n",
 				SVCFH_fmt(&argp->fh));
 -	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats);
+	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats, 0);
 	fh_put(&argp->fh);
 	RETURN_STATUS(nfserr);
 }

@@ -558,7 +558,8 @@ nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	resp->f_maxfilesize = ~(u32) 0;
 	resp->f_properties = NFS3_FSF_DEFAULT;
 -	nfserr = fh_verify(rqstp, &argp->fh, 0, NFSD_MAY_NOP);

Quoted 9 lines

fs/nfsd/nfs3proc.c nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle *argp,

Quoted 5 lines

fs/nfsd/nfs3proc.c +2 -0

+	nfserr = fh_verify(rqstp, &argp->fh, 0,
+			NFSD_MAY_NOP | NFSD_MAY_BYPASS_GSS_ON_ROOT);
  	/* Check special features of the file system. May request
 	 * different read/write sizes for file systems known to have
 

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Quoted 3 lines

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

I believe that the Solaris client may. I think that it may use the attributes returned from the FSINFO call, if there are any, to prevent the additional GETATTR, but this should be tested. It might also be interesting to test out a readonly failover mount on the Solaris client to see what behavior that that exhibits.

Quoted 11 lines · Peter Staubach

Quoted 9 lines · J. Bruce Fields

Quoted 4 lines · Peter Staubach

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

Quoted 6 lines

I believe that the Solaris client may. I think that it may use the attributes returned from the FSINFO call, if there are any, to prevent the additional GETATTR, but this should be tested. It might also be interesting to test out a readonly failover mount on the Solaris client to see what behavior that that exhibits.

OK, could be. Volunteers to test that welcomed--for now I think I'll stick to the list in the RFC.

Quoted 22 lines · J. Bruce Fields

Quoted 13 lines · Peter Staubach

Quoted 11 lines · J. Bruce Fields

Quoted 5 lines · Peter Staubach

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

Quoted 7 lines

I believe that the Solaris client may. I think that it may use the attributes returned from the FSINFO call, if there are any, to prevent the additional GETATTR, but this should be tested. It might also be interesting to test out a readonly failover mount on the Solaris client to see what behavior that that exhibits.

Quoted 3 lines

OK, could be. Volunteers to test that welcomed--for now I think I'll stick to the list in the RFC.

By the way, I don't mean to brush off the idea, it's just that this satisfies my immediate problem, and it would be extremely easy for someone else to test:

- Apply this patch to a linux nfs server, export a filesystem with
/export *(sec=krb5)
- mount -osec=krb5 server:/export from a solaris client.
- report whether it works, and get a packet capture if not.

... If someone gets a chance to figure out the Solaris client behavior, that'd be great.

Quoted 36 lines · J. Bruce Fields

Quoted 21 lines · J. Bruce Fields

Quoted 12 lines · Peter Staubach

Quoted 10 lines · J. Bruce Fields

Quoted 4 lines · Peter Staubach

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

Quoted 7 lines

I believe that the Solaris client may. I think that it may use the attributes returned from the FSINFO call, if there are any, to prevent the additional GETATTR, but this should be tested. It might also be interesting to test out a readonly failover mount on the Solaris client to see what behavior that that exhibits.

Quoted 3 lines

OK, could be. Volunteers to test that welcomed--for now I think I'll stick to the list in the RFC.

By the way, I don't mean to brush off the idea, it's just that this satisfies my immediate problem, and it would be extremely easy for someone else to test:

- Apply this patch to a linux nfs server, export a filesystem with
/export *(sec=krb5)
- mount -osec=krb5 server:/export from a solaris client.
- report whether it works, and get a packet capture if not.

Quoted 2 lines

... If someone gets a chance to figure out the Solaris client behavior, that'd be great.

I will try it when I can, but I was thinking of just watching the traffic generated during the mount. It shouldn't matter whether the mount is done with krb5 or not, the sequence of NFS operations should be the same.

Quoted 22 lines · J. Bruce Fields

Quoted 13 lines · Peter Staubach

Quoted 11 lines · J. Bruce Fields

Quoted 5 lines · Peter Staubach

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

Quoted 7 lines

I believe that the Solaris client may. I think that it may use the attributes returned from the FSINFO call, if there are any, to prevent the additional GETATTR, but this should be tested. It might also be interesting to test out a readonly failover mount on the Solaris client to see what behavior that that exhibits.

Quoted 3 lines

OK, could be. Volunteers to test that welcomed--for now I think I'll stick to the list in the RFC.

By the way, I don't mean to brush off the idea, it's just that this satisfies my immediate problem, and it would be extremely easy for someone else to test:

- Apply this patch to a linux nfs server, export a filesystem with
/export *(sec=krb5)
- mount -osec=krb5 server:/export from a solaris client.
- report whether it works, and get a packet capture if not.

... If someone gets a chance to figure out the Solaris client behavior, that'd be great.

The Solaris client behaves plus or minus like the Linux client. It generates a GETATTR unless it receives the attributes via one of the previous calls. In the Solaris case, it is an FSINFO call.

The current Linux NFS server does not return attributes for the PATHCONF, FSINFO, or FSSTAT calls.

Unless these calls are modified, then the NFSv3 GETATTR will need to be allowed for the same reason that the NFSv2 GETATTR is allowed. The NFS client needs, at the very least, the file type of the node that it is mounting.

I am confused as to how the testing could have been successful.

Quoted 8 lines · Peter Staubach

The Solaris client behaves plus or minus like the Linux client. It generates a GETATTR unless it receives the attributes via one of the previous calls. In the Solaris case, it is an FSINFO call.

The current Linux NFS server does not return attributes for the PATHCONF, FSINFO, or FSSTAT calls.

Hm. I don't know why that is.

Quoted 7 lines

Unless these calls are modified, then the NFSv3 GETATTR will need to be allowed for the same reason that the NFSv2 GETATTR is allowed. The NFS client needs, at the very least, the file type of the node that it is mounting.

I am confused as to how the testing could have been successful.

Well, you can try exporting a filesystem with sec=krb5:krb5i:krb5p (no sys) and try mounting v2 or v3, and you'll see that if fails without the patch, and succeeds with it.

But testing again (linux client and server), and taking a network trace this time: I mount with -overs=3,sec=krb5, and the client behavior is odd:

FSINFO call with auth_sys
GETATTR call with krb5
FSINFO call with krb5

Note that this client actually *does* have access to kerberos credentials--it's just not using them on the initial FSINFO call.

That could make some sense if it was trying to ensure the mount will succeed in the absence of kerberos credentials, and doesn't want to bother first trying to get a credentials and then falling back on auth_sys if it doesn't find them.

But currently it fails if the server requests auth_sys on the initial FSINFO *or* if it fails to get kerberos credentials for those second two rpc calls. Something similar seems to be true for v2. Huh.

Anyway, so in the Solaris v3 case I take it that what you're seeing is FSINFO, GETATTR, both done with auth_sys, and a failure of the mount command if both aren't permitted?

OK, so I agree the server should either permit v3 GETATTR (trivial, if arguably contrary to rfc 2623) or add attributes to FSINFO (which I assume is also easy, but I don't know why it was left out before). Seems the client needs some looking at too.

--b.

Quoted 34 lines · J. Bruce Fields

Quoted 8 lines · Peter Staubach

The Solaris client behaves plus or minus like the Linux client. It generates a GETATTR unless it receives the attributes via one of the previous calls. In the Solaris case, it is an FSINFO call.

The current Linux NFS server does not return attributes for the PATHCONF, FSINFO, or FSSTAT calls.

Hm. I don't know why that is.

Quoted 7 lines

Unless these calls are modified, then the NFSv3 GETATTR will need to be allowed for the same reason that the NFSv2 GETATTR is allowed. The NFS client needs, at the very least, the file type of the node that it is mounting.

I am confused as to how the testing could have been successful.

Well, you can try exporting a filesystem with sec=krb5:krb5i:krb5p (no sys) and try mounting v2 or v3, and you'll see that if fails without the patch, and succeeds with it.

But testing again (linux client and server), and taking a network trace this time: I mount with -overs=3,sec=krb5, and the client behavior is odd:

FSINFO call with auth_sys
GETATTR call with krb5
FSINFO call with krb5

Quoted 4 lines

Note that this client actually *does* have access to kerberos credentials--it's just not using them on the initial FSINFO call.

What happens if you perform this mount using autofs?

Quoted 66 lines · Peter Staubach

Quoted 60 lines · J. Bruce Fields

Quoted 47 lines · Peter Staubach

Quoted 44 lines · J. Bruce Fields

From: J. Bruce Fields <[email protected]>

RFC 2623 section 2.3.2 permits the server to bypass gss authentication checks for certain operations that a client may perform when mounting. In the case of a client that doesn't have some form of credentials available to it on boot, this allows it to perform the mount unattended. (Presumably real file access won't be needed until a user with credentials logs in.)

Being slightly more lenient allows lots of old clients to access krb5-only exports, with the only loss being a small amount of information leaked about the root directory of the export.

This affects on v2 and v3; v4 still requires authentication for all access.

Signed-off-by J. Bruce Fields <[email protected]>

---
 fs/nfsd/nfs3proc.c        |    5 +++--
 fs/nfsd/nfsfh.c           |   30 ++++++++++++++++++++----------
 fs/nfsd/nfsproc.c         |    6 ++++--
 fs/nfsd/vfs.c             |    4 ++--
 include/linux/nfsd/nfsd.h |    3 ++-
 5 files changed, 31 insertions(+), 17 deletions(-)

I intend to submit this for 2.6.28

fs/nfsd/nfs3proc.c +2 -0

index 4d617ea..1419142 100644
@@ -530,7 +530,7 @@ nfsd3_proc_fsstat(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	dprintk("nfsd: FSSTAT(3)   %s\n",
 				SVCFH_fmt(&argp->fh));
 -	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats);
+	nfserr = nfsd_statfs(rqstp, &argp->fh, &resp->stats, 0);
 	fh_put(&argp->fh);
 	RETURN_STATUS(nfserr);
 }

@@ -558,7 +558,8 @@ nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle    *argp,
 	resp->f_maxfilesize = ~(u32) 0;
 	resp->f_properties = NFS3_FSF_DEFAULT;
 -	nfserr = fh_verify(rqstp, &argp->fh, 0, NFSD_MAY_NOP);
+	nfserr = fh_verify(rqstp, &argp->fh, 0,

Quoted 10 lines

fs/nfsd/nfs3proc.c nfsd3_proc_fsinfo(struct svc_rqst * rqstp, struct nfsd_fhandle *argp,

Quoted 5 lines

fs/nfsd/nfs3proc.c +1 -0

+			NFSD_MAY_NOP | NFSD_MAY_BYPASS_GSS_ON_ROOT);
  	/* Check special features of the file system. May request
 	 * different read/write sizes for file systems known to have
 

I would think that you might want to have nfsd3_proc_getattr() in this list too. Some clients may need to generate a GETATTR if they need the attributes for the root node.

Quoted 4 lines

Do you know of any? rfc 2623 makes it sound like those clients are out of luck. And testing confirms that this patch is sufficient for the linux client, at least.

Quoted 7 lines

I believe that the Solaris client may. I think that it may use the attributes returned from the FSINFO call, if there are any, to prevent the additional GETATTR, but this should be tested. It might also be interesting to test out a readonly failover mount on the Solaris client to see what behavior that that exhibits.

OK, could be. Volunteers to test that welcomed--for now I think I'll stick to the list in the RFC.

A better description of the set of operations which should be allowed and which ones are not should include a discussion on the contents of the response to the FSINFO request. If the server returns attributes in the FSINFO response, then it does not need to allow unauthenticated GETATTR requests. If it does not return attributes in the FSINFO response, then it must allow unauthenticated GETATTR requests because this is required in order to allow clients to successfully mount file systems using strong authentication.

Quoted 9 lines · Peter Staubach

A better description of the set of operations which should be allowed and which ones are not should include a discussion on the contents of the response to the FSINFO request. If the server returns attributes in the FSINFO response, then it does not need to allow unauthenticated GETATTR requests. If it does not return attributes in the FSINFO response, then it must allow unauthenticated GETATTR requests because this is required in order to allow clients to successfully mount file systems using strong authentication.

Well... That's true for NFSv3, but if your server also supports NFSv2-with-RPCSEC_GSS, then it also has to support the NFSv2 FSSTAT +GETATTR under AUTH_SYS.

In any case, this is an issue of efficiency rather than security. Whether you allow FSINFO w/ post-op attributes but no GETATTR, or you allow FSINFO w/o post-op attributes and allow GETATTR on the mountpoint is entirely equivalent from the security viewpoint: the amount of information available using weak security is the same.