2016-09-23 11:01 GMT+02:00 Miklos Szeredi <miklos@xxxxxxxxxx>:
> On Wed, Sep 21, 2016 at 11:28 PM, Andreas Grünbacher
> <andreas.gruenbacher@xxxxxxxxx> wrote:
>
>> 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.
>
> The xattr representation of posix acls is linux specific as far as I
> understand. By passing this representation to fuse filesystems it
> becomes part of the fuse protocol. This doesn't necessarily mean that
> we have to actually decode the acl in the fuse library, but it needs
> to be documented at least.
>
> BTW, I find it strange that the xattr representation of posix acls are
> not in any uapi header files.
Yes, that should be moved. Those headers are quite a bit older than
the uapi split.
>>> 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.
>
> Does librichacl have xattr->acl and acl->xattr conversion functions?
Yes, for things like ceph and glusterfs.
> Because libacl seems to lack these...
In libacl, those functions are internal to the library. We could start
exporting them, but the in-memory ACL representation isn't exactly
great for many use cases, like fuse probably.
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
