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:
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
