Implementing ACL support in a distributed filesystem, with macOS and Linux clients talking to a remote file server, requires compatibility between the ACL models supported in Darwin-XNU and Linux kernels to be taken into consideration.
My filesystem does support EAs to facilitate ACL storage and retrieval. So setting ACLs via chmod(1) and retrieving them via ls(1) does work.
However, the macOS and Linux ACL models are incompatible and would require some sort of conversion between them.
chmod(1) uses acl(3) to create ACL entries.
While acl(3) claims to implement POSIX.1e ACL security API, which, to the best of my knowledge, Linux VFS implements as well, their respective implementations of the standard obviously do differ. Which is also stated in acl(3):
This implementation of the POSIX.1e library differs from the standard in a number of non-portable ways in order to support the MacOS/Darwin ACL semantic.
Then there's this NFSv4 to POSIX ACL mapping draft that describes the conversion algorithm.
What's the recommended way to bridge the compatibility gap there, so that macOS ACL rules are honoured in Linux and vice versa?
Thanks.
What's the recommended way to bridge the compatibility gap there, so that macOS ACL rules are honoured in Linux and vice versa?
I'm not aware of any guidance and I'm not sure there is any way to really create a bridge that's provides consistent behavior on both platforms. That also assumes you have the implementation flexibility to implement any behavior you want. Most distributed file systems are built on top of some other host/file system, which means they're actually constrained by the design underneath them, not by the connecting system. To put that another way, there are multiple "views" of the file system ACL state- the "views" individual clients create (based on the data exposed by your file system) and the "truth", meaning how your file system will actually behave.
The NFS ACL mapping draft is actually talking about this dynamic from the client's perspective when it says:
The language of [1] allows a server some flexibility in handling ACLs that it cannot enforce completely accurately, as long as it adheres to "the guiding principle... that the server must not accept ACLs that appear to make [a file] more secure than it really is."
What that's really saying is that:
-
It's acceptable for "the truth" to be more restrictive than a client's "view".
-
It's NOT acceptable for "the truth" to be less restrictive than a client's "view".
I'll also add to that that part of what "the truth" implies is that my ability to access data should NOT vary based on the client I happen to be connecting with.
That leads to here:
However, the macOS and Linux ACL models are incompatible and would require some sort of conversion between them.
You basically have three choices in how to handle this incompatibility:
-
Determine a configuration set the both systems can accurately represent and artificially restrict "the truth" to THAT specific configuration. This provides a coherent "view" to all clients but reduces flexibility.
-
Create the "best" mapping from "the truth" to the client for each operating system and ignore the presentation inconstancies this will create on other clients. This provides the most flexibility but means that what you're able to configure will vary depending on the client.
-
Expose the configuration set of #1 to the clients, but allow "the truth" to be fully configured through side channels (for example, by editing the ACL configuration of the hosting server or through dedicated server tools/apps). This is basically a hybrid of #1 & #2, as it creates a consistent "appearance" between all clients while still allowing the creation of configurations the client can't represent.
There isn't any single "right" choice within those options, as it really depends on the specifics of what you're creating and how you want your product to work.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
