On Wed, Aug 28, 2019 at 09:26:20PM +0000, Trond Myklebust wrote: > On Wed, 2019-08-28 at 17:06 -0400, bfields@xxxxxxxxxxxx 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.
