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. 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. > (not all administrators think about the size of > ACLs when they add hundreds of users or groups or apps to ACLs). > > The bigger problem is that when ACLs are created -- after -- the file > is created there is a potential race (harder to deal with in cluster > and network file systems). Ideally we should be able to optionally > pass all the security information needed to create a file in the > create call itself. For apps which don't care they can continue to > use the old syscalls. That would be most of them, I'd think. But I suppose windows apps (via Samba or Wine?) could use this. Definitely a project for another day, in any case. --b. > In cifs.ko I still need to enable the SMB3 ACL helper functions > (currently only enabled for the older cifs dialect) since that will > make it easier, and figure out a way to allow helper tools to view > "claims based ACLs" (DAC), not just traditional > CIFS/NTFS/SMB3/RichACLs. > -- > Thanks, > > Steve _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
