Messages in this thread | | | Date | Tue, 10 Nov 2015 14:17:45 -0500 | From | "J. Bruce Fields" <> | Subject | Re: [PATCH v15 00/22] Richacls (Core and Ext4) |
| |
On Tue, Nov 10, 2015 at 06:58:19PM +0100, Andreas Gruenbacher wrote: > On Tue, Nov 10, 2015 at 6:07 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote: > >> I don't have strong disagreement with using pseudo-xattrs to > >> store/retrieve ACLs (we already do this) but retrieving/setting an ACL > >> all at once can be awkward when ACLs are quite large e.g. when it > >> encodes to over 1MB > > > > At least in the NFS case, that's also a limitation of the protocol. > > I couldn't find a limit in the NFSv4 specification, but the client and > server implementations both define arbitrary ACL size limits. In > addition, the xattr syscalls allow attributes to be up to 64k long.
I don't recall 4.0 specifying any limit, 4.1 does include negotiation of maximum rpc calls and replies, and that effectively limits ACL sizes since they have to fit in a single rpc.
> The bigger problem would be incrementally setting ACLs. To prevent > processes from racing with each other, we would need a locking > mechanism. In addition, the memory overhead would be prohibitive and > access decisions would become extremely slow; we would have to come up > with mechanisms to avoid those problems.
Right. Anyway, not worth the trouble, I think.
(Though what might be worth thinking about at some point is just making sure we fail in helpful ways.)
--b.
| |