On Tue, Nov 10, 2015 at 6:07 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote: >> On Tue, Nov 10, 2015 at 6:39 AM, Andreas Gruenbacher >> <agruenba@xxxxxxxxxx> wrote: >> > On Tue, Nov 10, 2015 at 12:29 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >> >> On Mon, Nov 09, 2015 at 12:08:41PM +0100, Andreas Gruenbacher wrote: >> >>> Here is another update to the richacl patch queue. This posting contains >> >>> the patches ready to be merged; the patches later in the queue still need >> >>> some more review. >> <snip> >> >> and still abuses xattrs instead of a proper syscall interface. >> >> That's far from being ready to merge. >> > >> > The xattr syscall interface is what's used for very similar kinds of >> > things today; using it for richacls as well sure does not count as >> > abuse. Things could be improved in the xattr interface and in its >> > implementation, but we need more substantial reasons than that for >> > reimplementing the wheel once again. >> >> 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. > If > we really wanted to support massive ACLs then we'd need both syscall and > NFS interfaces to allow incrementally reading and writing ACLs, and I > don't even know what those would look like. > > So this is a fine limitation as far as I'm concerned. 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. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
