> On Oct 21, 2024, at 6:33 PM, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > On Mon, Oct 21, 2024 at 7:45 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> >> >>> 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? > Nope, it doesn't need to be... > Well, this in embarrassing (blush!). > It turns out it works fine for GETATTR of a large ACL (either the > acl attribute or the new ones added by the patch). > > For the client side, I could have sworn I needed to do the > "fill in the page stuff" to get the large one to work for SETATTR, > but for the knfsd, it figures it out. > > Btw, I was only able to get to about 60K, because the ext4 fs > I have on the server wouldn't allow an ACL with 1000 entries to > be set (replied with out of space on device). > --> I did get one with 455 entries to work and most of those entries > were for 110 byte group names. IIRC the Linux file systems have a 64KB length limit on extended attributes, where ACLs are stored. ENOSPC is a little strange. > So, what can I say, except I should have tried it before I posted. > (One gotcha is that FreeBSD only handles 32 ACE ACLs, but > when you look at the packet trace, you can see they are all in > the GETATTR reply. Not an excuse, but...) > > Thanks for the reply Chuck, rick > >> >> >>> 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 -- Chuck Lever
