Prime time client-only access control

[csabahenk]

Access control can be executed either on client or server side... or both... which is the typical case.

It's an architectural feature of Glusterfs that all authenticated clients are trusted in the sense that they are capable to incur any change to the assets held by the server. The server and clients constitute a single domain of security. Therefore it is sufficient to guarantee a single point in the data path where access control takes place. Doing it twice is redundant.

Fuse clients perform access control unconditionally -- either along POSIX mode bits semantics, delegated to the kernel (that's the default), or along ACL semantics, in the client's own scope (that's implied by the --acl glusterfs option (-oacl mount option)). Such a definite statement can't be made about clients in general, but we do know this about fuse clients.

Therefore if in a given Glusterfs cluster it is granted that all clients are fuse clients, this ensures a client side point of access control in all data paths, thus rendering server side access control unnecessary. Furthermore, the only server side component that makes use of group membership on server side is the access control translator, so if we ditch it, then querying group membership on server side or to transferring it from client to server side also becomes unnecessary.

Dropping these unnecessary services brings on a considerable performance benefit, according to customer feedback. Therefore this kind of setup should be given prime time and advertised as a suggested mode of operation (with emphasis on the condition of entertaining only fuse clients).

---

State of the art:

Such a setup is technically feasible since Glusterfs 9.0:

• this release brought in the features.acl volume option, through which server side access control can be disabled;
• server side querying of group membership can be disabled through the server.manage-gids volume option;
• sending group list from client to server side can be disabled through the client.send-gids option.

However, there are issues to be addressed:

• the documentation discusses at length how precise knowledge of group membership on server side can be achieved in various circumstances, without considering any scenario where ensuring this condition is not necessary, thus tacitly implying the necessity of server side access control (see Administration Guide / Handling of users that belong to many groups, canonical publication of document / snapshot of current version of document on Github);
• features.acl and client.send-gids are labeled as diagnostic / developer-oriented options and not documented as part of the administrative interface (NO_DOC flag is set);
• furthermore, naming of the features.acl option can result in misunderstanding, suggesting it does something related to ACL-s, probably getting mixed up with client's --acl / -oacl, which indeed does control ACL enablement (it's true that the same translator is used on server side for access control that performs ACL checking on client side, but the server side instance is not decisive wrt. adherence to ACL semantics), so this option is better renamed in a way that is upfront about its intent.

The first of these items belongs to the scope of the glusterdocs project; I just mention it here for sake of completeness and to demonstrate the current mindset. The latter two can be addressed in the glusterfs scope.

glusterfs version:

Glusterfs 9.0 - 10.1

[csabahenk]

Update on "technical feasiblity": it turned out that client.send-gids does not work as advertised; @xhernandez has diagnosed the issue and will send a fix.

[stale[bot]]

Thank you for your contributions. Noticed that this issue is not having any activity in last ~6 months! We are marking this issue as stale because it has not had recent activity. It will be closed in 2 weeks if no one responds with a comment here.

[stale[bot]]

Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it.