Hi all, Unfortunately it is impossible to validate non-trusted volfiles using existing glusterfs options. Semantic and format of values passed by the --xlator-option don't allow to "deliver" trusted values without compromises with security. So I have added a new --secure-xlator-option, Please, review: review.gluster.org/8657 Thanks, Edward. On Wed, 13 Aug 2014 12:26:29 -0700 Anand Avati <avati@xxxxxxxxxxx> wrote: > +1 for all the points. > > > On Wed, Aug 13, 2014 at 11:22 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> > 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 > > Gluster-devel@xxxxxxxxxxx > > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
