[04/43] nfsd4: reserve head space for krb5 integ/priv info

Commit Message

Bruce Fields May 11, 2014, 8:52 p.m. UTC

From: "J. Bruce Fields" <[e-mail]>

Currently if the nfs-level part of a reply would be too large, we'll
return an error to the client.  But if the nfs-level part fits and
leaves no room for krb5p or krb5i stuff, then we just drop the request
entirely.

That's no good.  Instead, reserve some slack space at the end of the
buffer and make sure we fail outright if we'd come close.

The slack space here is a massive overstimate of what's required, we
should probably try for a tighter limit at some point.

Signed-off-by: J. Bruce Fields <[e-mail]>
---
 fs/nfsd/nfs4proc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Christoph Hellwig May 12, 2014, 5:37 a.m. UTC | #1

On Sun, May 11, 2014 at 04:52:09PM -0400, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <[e-mail]>
> 
> Currently if the nfs-level part of a reply would be too large, we'll
> return an error to the client.  But if the nfs-level part fits and
> leaves no room for krb5p or krb5i stuff, then we just drop the request
> entirely.
> 
> That's no good.  Instead, reserve some slack space at the end of the
> buffer and make sure we fail outright if we'd come close.
> 
> The slack space here is a massive overstimate of what's required, we
> should probably try for a tighter limit at some point.

Don't we know the rpc auth scheme at this point and can at least
avoid it for non-krb setups?

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bruce Fields May 12, 2014, 9:45 p.m. UTC | #2

On Sun, May 11, 2014 at 10:37:27PM -0700, Christoph Hellwig wrote:
> On Sun, May 11, 2014 at 04:52:09PM -0400, J. Bruce Fields wrote:
> > From: "J. Bruce Fields" <[e-mail]>
> > 
> > Currently if the nfs-level part of a reply would be too large, we'll
> > return an error to the client.  But if the nfs-level part fits and
> > leaves no room for krb5p or krb5i stuff, then we just drop the request
> > entirely.
> > 
> > That's no good.  Instead, reserve some slack space at the end of the
> > buffer and make sure we fail outright if we'd come close.
> > 
> > The slack space here is a massive overstimate of what's required, we
> > should probably try for a tighter limit at some point.
> 
> Don't we know the rpc auth scheme at this point and can at least
> avoid it for non-krb setups?

Yes.  At the end of this series we have RPC_MAX_AUTH_SIZE scattered
around in a few different places.  Rather than have each place have some
flavor-specific logic I think I'd like the auth code to set an
rq_auth_slack field in the struct svc_rqst for code like this to use.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Christoph Hellwig May 13, 2014, 5:05 a.m. UTC | #3

On Mon, May 12, 2014 at 05:45:45PM -0400, J. Bruce Fields wrote:
> Yes.  At the end of this series we have RPC_MAX_AUTH_SIZE scattered
> around in a few different places.  Rather than have each place have some
> flavor-specific logic I think I'd like the auth code to set an
> rq_auth_slack field in the struct svc_rqst for code like this to use.

That sounds pretty reasonable to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 6c049c4..3d4b044 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1259,7 +1259,7 @@  static void svcxdr_init_encode(struct svc_rqst *rqstp, struct nfsd4_compoundres
 
 	xdr->buf = buf;
 	xdr->p   = head->iov_base + head->iov_len;
-	xdr->end = head->iov_base + PAGE_SIZE;
+	xdr->end = head->iov_base + PAGE_SIZE - 2 * RPC_MAX_AUTH_SIZE;
 }
 
 /*