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 (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. In the meantime, I don't mind the approach of staging this in via a pseudo-xattr, Samba can deal with that (and it will make some of the backup and data movement tools easier for the cifs.ko client which currently rely on a cifs specific xattr). 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
