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