Responding to this from the Gerrit commit:
"glusterd security settings are too coarse,
so that if we made it possible for an unprivileged gsyncd
to operate, we would open up too far."
This is related to an issue that we (in HekaFS-land) have with glusterd, and the solution might be the same: use the SSL-transport code to identify users via certificates, and then implement proper role-based access control based on those identities. If such mechanisms were in place in glusterd, would there even be a need for separate mechanisms in georep to ensure this kind of safety/security?

(In reply to comment #3)
> Responding to this from the Gerrit commit:
>
> "glusterd security settings are too coarse,
> so that if we made it possible for an unprivileged gsyncd
> to operate, we would open up too far."
>
> This is related to an issue that we (in HekaFS-land) have with glusterd, and
> the solution might be the same: use the SSL-transport code to identify users
> via certificates, and then implement proper role-based access control based on
> those identities. If such mechanisms were in place in glusterd, would there
> even be a need for separate mechanisms in georep to ensure this kind of
> safety/security?
You are right -- had we a proper auth + RBAC system in place, that could be used to implement the needed access control mechanism for geo-rep. However, as of now, given that we do not have such a thing at hand, the design philosophy I followed is just... KISS. This has the advantage that what has been / is being done for geo-rep is by-and-large the common denominator of any kind of access control work, and thus I highly hope that most of the code we write will be durable. In particular,
- We have added the mountbroker service by which it's possible to request a mount of a volume from glusterd. As of now, handling of the MOUNT message is implemented with a minimalistic authentication mechanism (so we didn't give a chance for ourselves to get it wrong ;)) -- indeed, we put emphasis on making sure that noone can access the mount except for the one whom should. If later on glusterfs will get a proper authentication framework, the mountbroker backend can be kept and the needed auth hooks can be added.
- The sentence you are quoting above refers to the need of adding a layer to glusterd RPC by which messages from cli to glusterd can be selectively allowed / rejected. As of now, the logic for selection will be just checking for the privilegedness of the requestor (by the good old privileged port binding hack). Instead of this logic, we can later plug in some more sophisticated cert-based mechanism -- but the need for the ability of distinguishing between various cli ops will not go away, so again, the core code can be kept.