Re: Maximum Number of ACL on NFSv4

["bfields@fieldses.org" <bfields@fieldses.org>]

On Wed, Aug 28, 2019 at 09:26:20PM +0000, Trond Myklebust wrote:
> On Wed, 2019-08-28 at 17:06 -0400, bfields@fieldses.org wrote:
> > On Wed, Aug 28, 2019 at 08:25:16PM +0000, Trond Myklebust wrote:
> > > Umm... Don't forget that NFSv4 ACL aces are typically much larger
> > > than
> > > POSIX ACL aces because the user/group names are encoded as strings,
> > > not
> > > binary uids and gids.
> > > 
> > > IOW: The size of the RPC message is likely to be a lot larger than
> > > the
> > > resulting POSIX ACL...
> > 
> > Actually this limit is post-idmapping, but, yes, before NFSv4->Posix
> > mapping (complicated in itself), which is why I talked about having
> > to
> > estimate.
> > 
> > More interested to hear what you think about whether we need a limit
> > at
> > all.  Do we have any ideas how big is too big a number to pass to
> > kmalloc?  Or is it OK to just let anything through and let kmalloc
> > fail?
> > 
> 
> A NFSv4.x client is always required to respect the max request size as
> negotiated during CREATE_SESSION, so there is an upper limit right
> there. On Linux, the client will never try to negotiate a limit greater
> than 1MB.

The limit's actually a sanity check on the number of ACEs.  Since that's
what we're about to use in the kmalloc; in the ACL xdr decoding:

	if (nace > NFS4_ACL_MAX)
		return nfserr_fbig;

	*acl = svcxdr_tmpalloc(argp, nfs4_acl_bytes(nace));

Maybe the simplest thing is only to reject an nace value that'd be
impossible given the size of the rpc call.

--b.