2016-09-21 10:30 GMT+02:00 Miklos Szeredi <miklos@xxxxxxxxxx>: > [Adding Andreas Gruenbacher to Cc] > > On Mon, Aug 29, 2016 at 3:46 PM, Seth Forshee > <seth.forshee@xxxxxxxxxxxxx> wrote: >> Hi Miklos, >> >> Here's an updated set of patches for supporting posix ACLs in fuse. I >> think I've incorporated all the feedback from the last RFC series, and >> so I've dropped the RFC this time. > > Pushed, with minor changes, to > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#for-next > > Please verify that I didn't break it. > >> I also pushed to github the changes I made to libfuse for testing this. >> They're a little rough and probably not 100% complete, but it is >> sufficient for exercising the functionality of these patches with >> fusexmp. >> >> https://github.com/sforshee/libfuse/tree/posix-acl > > As for the libfuse part: > > 1) Please don't mess with fusexmp.c. The added code is really an > anti-example. Posix acls will will work fine in such pass-through > filesystems without doing anything. The added complexity just makes > it brittle and racy without actually doing anything positive. > > 2) You define some constants and structures (POSIX_ACL_*) in > fuse_common.h that don't seem to belong there. There's <sys/acl.h> > that contains some parts of that, but I'm not sure how much we want to > tie libfuse to libacl... It's a difficult thing. Generally I'd try > to keep the interface as narrow as possible. Perhaps it's enough to > have a a function to return the equivalent mode from the xattr? Using definitions from <sys/acl.h> doesn't necessarily create a runtime dependency on libacl. What does fuse actually need to do with POSIX ACLs? I understand that setxattr("system.posix_acl_access") updates both the access ACL and the file mode, and so does chmod. Both these operations can be implemented quite easily based in the xattr value though; I wouldn't choose to use libacl for that. > 3) How will richacl's fit into this? Richacls work similar to POSIX ACLs from fuse's point of view. The algorithms for updating a richacl upon a chmod and for computing the new file mode from setxattr("system.richacl") are significantly more complicated though; also, librichacl isn't as over engineered as libacl, so I would use librichacl for these operations. > 4) We really need a better example to check the efficiency of the new > interface, but that's hard because we need a "real" filesystem for > that and those are rare. Ntfs-3g is one such, and it would be > interesting to "port" it to using the new API. NTFS would be a good fit for supporting Richacls as well, obviously. 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
