Mountbroker is a glusterd service.
Its purpose is to make it possbile in a safe way for unprivileged processes to "own" a certain glusterfs mount, access controlled and orchestrated by glusterd.
It's configuration can be described by a DSL. As of now, it can be configured through the glusterd volfile, where a mountbroker config directive appears as a value for some option. Therefore, syntactically, the DSL is made to be compatible with the syntactical constraints of that role. Semantically, a config directive is a predicatecomposed of set-theoretical properties over the domain of set of strings. The kind of set of strings we think of here is a set of glusterfs options. Regarding volfile options, there is a dedicated option for the use case of geo-replication which refers to a pre-prepared mountbroker config directive that is usable for geo-rep's purposes.
It's implemented as a standard RPC service, with glusterd as server and gluster cli as client, consisting of the messages mount and umount.
After deciding whether a mount request is permitted as of the configuration, if yes, it creates a gluster mount that is accessible only for a certain pid (determined by config). An alias (symlink) of the mount point is returned to the client through which it can access the mount. The alias is private, only glusterd and the client will know it (and root privileges necessary to find out about it). When the client is done with the mount, It's expected to send the alias as the parameter of the umount message. Properly done, glsuterd unmounts the mount.
To make mount ownership possible, we implement the --user-map-root=<user> glusterfs option, which, if given, replaces the uid of <user> with 0 at the FUSE level (in the uid field of fuse_in_header).
Set-theoretic keywords: SUB, SUP, EQL, MEET, SUB+.
A simple predicate looks like <keyword>( <sequence of (whitespace-free) strings separated with whitespace or '|'> ). Excess whitespace is allowed. A given element of the string sequence will be referred to as an optpattern.
A configuraton directive is a sequence of simple predicates, optionally separated by &, piecewise optionally prefixed with -. Excess whitespace is allowed.
We define the following matching relation between an optpattern and a string: we decompose them to the first equeality symbol (if there is one). The pre-equality parts must be equal as strings. The post-equality part of the optpattern should match the post-equality part of the string as a glob pattern (cf. fnmatch(3)).
A set of strings fulfils a simple predicate of type SUB if its a subset of its optpatterns (using the above define match relation to decide about containment). Similarly, SUP, EQL, MEET assert set-theoretical superset, equality, non-empty intersection. SUB+ is a variant of SUB which automatically includes the optpattern set of the latest SUP predicate. The - symbol negates a simple predicate. A configuration directive asserts the conjunction if its members.
option mountbroker-root <path>
The directory under which mountbroker mounts and their registry is performed. It's presence is regarded as the enablement of the mountbroker service. To avoid foot-shooting, a sanity check is made against <path> upon startup, regarding ownership and permissions.
option mountbroker.<label> <mountborker config directive>
Registers the config directive with <label>.
option mountbroker-geo-replication.<label> <volname>:<user>
Alias for mountbroker, with following config directive:
SUP(
xlator-option=\\*-dht.assert-no-child-down=true
volfile-server=localhost
client-pid=-1
volfile-id=<volname>
user-map-root=<user>
)
SUB+(
log-file=/var/log/glusterfs/geo-replication*/*
log-level=*
)
.
option mountbroker-geo-replication.<user> <volname>
Alias for
option mountbroker-geo-replication.<user> <volname>:<user>
A mount request sends a label string and a set of glusterfs long options that are asked to be passed to glusterfs, leading -- stripped. If mountbroker is enabled, and label is registered with glusterd, glusterd evaiuates the respective config directive against the incoming option set. If it's not fulfilled, the request is refused. If fulfilled, glusterd next tries to deduce an action from the option set: checks for unique occurrences of options of the form volume-id=* and user-map-root=*, and extracts the volume id and uid from them (not found unambiguously, the request is refused).
Then glusterfs is invoked with the given options, on a safely generated temporary mountpoint, and the symlink referred in the overview is created and returned in reply.
Given the symlink aliases are not known for third party, it suffices to see if the requested path is within the appropriate directory. If yes, we can try to unmount it. That is, no in-memory regisrty is made with the aliases -- the filesystem is the registry.
Umount request has one parameter beyond the path, a flag which enables lazyness.
- The first version of the DSL had explicit action specifiers too, but for sake of simplicity those were droped -- what to do is deducible from the option set.
- I was thinking of adding "transformative" directives, ie. server-side knobs how the client-side option set should be transformed (think of extending with some static server side additions, so that the server can enforce certain features like log level). On the contrary, the option set is now explicitly negotiated in between the client and server, the client must be clear about the server's whims (you can enforce a certain log level, but for that client must be aware of that requirement). I did not see a definite need for tranformative directives, therefore I did not added them. We can discuss such an extension if indeed it's needed. Another possible approach, suitable for uses with client written in high-level languages, that we extend the RPC interface so that it's possible to query the mountbroker config, and then it would be left to the client to apply some intelligence to come up with a compatible option set.