I'm planning on implementing NFSv4 -> POSIX ACL mapping in FSAL_VFS.
My main target is Lustre. I can see several ways of approaching
this, most of them not Lustre-specific, so I thought I'd throw some
questions out here, gather opinions and then attempt the implementation.
I'm relatively new to the NFS Ganesha codebase, having dived into a
couple of areas in recent months. However, I have quite solid open
source experience, primarily in Samba.
I was hoping to post a proof-of-concept implementation but there are
too many decisions to make that result in quite different code and
different amounts of code... so I'll ask questions first. :-)
There are several parts to this:
* Coding vfs_set_acl() and vfs_get_acl() functions, or similar
* Plugging set_acl()/get_acl() functions in via setattr()/getattr()
functions
* Enabling calls to test_access() and similar
Coding vfs_set_acl() and vfs_get_acl() functions
------------------------------------------------
This looks quite straightforward, depending on where it is implemented.
FSAL_GLUSTER & FSAL_CEPH provide good examples - I have a
proof-of-concept implementation of this.
Use fsal_acl_2_posix_acl()/posix_acl_2_fsal_acl() to do the
translation. Use libacl to read/write the POSIX ACLs, or existing
FSAL_VFS code to read/write extended attributes and use
xattr_2_posix_acl()/posix_acl_2_xattr() to translate them. At the
moment I've done the latter because I followed the FSAL_CEPH example.
I'd like advice on whether using libacl is likely to be acceptable,
since it should mean less code.
Plugging set_acl()/get_acl() functions in via setattr()/getattr() functions
---------------------------------------------------------------------------
I can see 2 main options for doing this:
* Inline in FSAL_VFS/file.c, in vfs_setattr2() and probably
vfs_getattr()
If a "global" FSAL_VFS implementation is acceptable then this seems
like the most straightforward way.
* In the vfs subfsal, via sub_ops->{getattrs,setattrs}
This seems like the cleanest way of structuring it. If we go this
route then I hope that libacl is acceptable, since it will help
avoid factoring out the extended attribute code to avoid layering
violations.
This could even go further "down" into the Lustre subfsal, but that
doesn't seem necessary, since everything sane seems to implement POSIX
ACLs, so everyone can share the joy (and the bugs ;-).
Enabling calls to test_access() and similar
-------------------------------------------
There are sections of code currently enclosed in:
#ifdef ENABLE_VFS_DEBUG_ACL
Most of that code looks to be generic, so it should work with a real
ACL implementation too.
My first guess is that I could change nearly all of these to:
#ifdef ENABLE_VFS_ACL
or similar, and have ENABLE_VFS_ACL defined when either
ENABLE_VFS_DEBUG_ACL or (say) ENABLE_VFS_POSIX_ACL is defined.
Please let me know whether any of this makes sense... and which way I
should go for the major decisions... :-)
Thanks!
peace & happiness,
martin
Show replies by date
On Wed, Mar 16, 2022 at 4:56 AM Martin Schwenke <martin(a)meltin.net> wrote:
I'd like advice on whether using libacl is likely to be acceptable,
since it should mean less code.
Off hand I can't imagine why not. libacl is already used in both
FSAL_GLUSTER and FSAL_CEPHFS.
--
Kaleb
Yea, that shouldn’t be a problem.
Frank
From: Kaleb Keithley [mailto:kkeithle@redhat.com]
Sent: Wednesday, March 16, 2022 4:42 AM
To: Martin Schwenke <martin(a)meltin.net>
Cc: Ganesha-devel <devel(a)lists.nfs-ganesha.org>
Subject: [NFS-Ganesha-Devel] Re: Implementing NFSv4 -> POSIX ACL mapping in FSAL_VFS
On Wed, Mar 16, 2022 at 4:56 AM Martin Schwenke <martin(a)meltin.net
<mailto:martin@meltin.net> > wrote:
I'd like advice on whether using libacl is likely to be acceptable,
since it should mean less code.
Off hand I can't imagine why not. libacl is already used in both FSAL_GLUSTER and
FSAL_CEPHFS.
--
Kaleb