> On Oct 20, 2024, at 7:09 PM, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > Hi, > > As some of you will already know, I have been working on patches > that add support for POSIX draft ACLs to NFSv4.2. > The internet draft can be found here, if you are interested. > https://datatracker.ietf.org/doc/draft-rmacklem-nfsv4-posix-acls/ > > The patches now basically work, but handling of large POSIX > draft ACLs for the server side is not done yet. > > A POSIX draft ACL can have 1024 aces and since a "who" field > can be 128 bytes, a POSIX draft ACL can end up being about 140Kbytes > of XDR. Do both the default and access ACLs for a directory and it > could be 280Kbytes. (Of course, they usually end up much smaller.) > > For the client side, to handle large ACLs for SETATTR (which never > sets other attributes in the same SETATTR), I came up with some > simple functions (called nfs_xdr_putpage_bytes(), nfs_xdr_putpage_word() > and nfs_xdr_putpage_cleanup() in the current client.patch) which > fill the large ACL into pages. Then xdr_write_pages() is called to > put them in the xdr stream. > --> Whether this is the right approach is a good question, but at > least it seems to work. > > For the server, the problem is more difficult, since a GETATTR reply > might include encodings of other attributes. (At this time, the proposed > POSIX draft ACL attributes are at the end, since they have the highest > attribute #s, but that will not last long.) > > The same technique as for the client could be used, but only if there > are no attributes that come after the POSIX draft ACL ones in the XDR > for GETATTR's reply. > > This brings me to one question... > - What do others think w.r.t. restricting the POSIX draft ACLs to only > GETATTR (and not a READDIR reply) and only with a limited set > of other attributes, which will all be lower #s, so they come before > POSIX draft ACL ones? > --> Since it is only a personal draft at this time, this requirement > could easily be added and may make sense to limit the size > of most GETATTRs. > This restriction should be ok for both the LInux and FreeBSD clients, > since they only ask for acl attributes when a getfacl(1) command is > done and do not need a lot of other attributes for the GETATTR. Generally, I don't immediately see why POSIX ACLs need a restriction that the protocol doesn't already have for NFSv4 ACLs. > Alternately, there needs to be a way to build 280Kbytes or more > of XDR for an arbitrary GETATTR/READDIR reply. IIUC, NFSD already handles this for both READDIR and NFSv4 ACLs (and perhaps also GETXATTR / LISTXATTR). So I'll have to have a look at your specific implementation, maybe sometime this week. I can't think of a reason that our current XDR and NFSD implementation wouldn't handle this, but haven't thought deeply about it. It might not be efficient for large ACLs, but does it need to be? > Btw, I have not tested to see what happens if a large POSIX draft > ACL is set for a file (locally on the server, for example) and then > a client does a GETATTR of the acl attribute (which replies with > a NFSv4 ACL created by mapping from the POSIX draft ACL). > --> I have a hunch it will fail, but I need to test to be sure? > > Thanks in advance for any comments w.r.t. this issue, rick > ps; In particular, I'd like to know what others think about adding > the restriction on acquisition of the POSIX draft ACLs by GETATTR. -- Chuck Lever
