+1 for all the points.
On Wed, Aug 13, 2014 at 11:22 AM, Jeff Darcy <[email protected]> wrote: > > I.1 Generating the master volume key > > > > > > Master volume key should be generated by user on the trusted machine. > > Recommendations on master key generation provided at section 6.2 of > > the manpages [1]. Generating of master volume key is in user's > > competence. > > That was fine for an initial implementation, but it's still the single > largest obstacle to adoption of this feature. Looking forward, we need > to provide full CLI support for generating keys in the necessary format, > specifying their location, etc. > > > I.2 Location of the master volume key when mounting a > > volume > > > > > > At mount time the crypt translator searches for a master volume key on > > the client machine at the location specified by the respective > > translator option. If there is no any key at the specified location, > > or the key at specified location is in improper format, then mount > > will fail. Otherwise, the crypt translator loads the key to its > > private memory data structures. > > > > Location of the master volume key can be specified at volume creation > > time (see option "master-key", section 6.7 of the man pages [1]). > > However, this option can be overridden by user at mount time to > > specify another location, see section 7 of manpages [1], steps 6, 7, > > 8. > > Again, we need to improve on this. We should support this as a volume > or mount option in its own right, not rely on the generic > --xlator-option mechanism. Adding options to mount.glusterfs isn't > hard. Alternatively, we could make this look like a volume option > settable once through the CLI, even though the path is stored locally on > the client. Or we could provide a separate special-purpose > command/script, which again only needs to be run once. It would even be > acceptable to treat the path to the key file (not its contents!) as a > true volume option, stored on the servers. Any of these would be better > than requiring the user to understand our volfile format and > construction so that they can add the necessary option by hand. > > > II. Check graph of translators on your client machine > > after mount! > > > > > > During mount your client machine receives configuration info from the > > non-trusted server. In particular, this info contains the graph of > > translators, which can be subjected to tampering, so that encryption > > won't be invoked for your volume at all. So it is highly important to > > verify this graph. After successful mount make sure that the graph of > > translators contains the crypt translator with proper options (see > > FAQ#1, section 11 of the manpages [1]). > > It is important to verify the graph, but not by poking through log files > and not without more information about what to look for. So we got a > volfile that includes the crypt translator, with some options. The > *code* should ensure that the master-key option has the value from the > command line or local config, and not some other. If we have to add > special support for this in otherwise-generic graph initialization code, > that's fine. > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://supercolony.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-devel
