Re: [PATCH] esx: Use MD5 sum of mount path as storage pool UUID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 12, 2010 at 01:40:14AM +0200, Matthias Bolte wrote:
> 2010/8/9 Justin Clift <jclift@xxxxxxxxxx>:
> > On 08/09/2010 06:56 AM, Matthias Bolte wrote:
> >>
> >> With the previous storage pool UUID source not all storage pools
> >> had a proper UUID, especially GSX storage pools. The mount path
> >> is unique per host and cannot change during the lifetime of the
> >> datastore. Therefore, its MD5 sum can be used as UUID.
> >>
> >> Use gnulib's crypto/md5 module to generate the MD5 sum.
> >
> > Just as a general thought, would it be preferably to use the SHA1 function
> > instead of the MD5 one?
> 
> Every non-trivial hash function will do for the purpose of deriving a
> UUID from the mount path.
> 
> > Asking because MD5 seems to be trending "out of favour" (as a
> > generalisation) compared to SHA1, after some cryptographers showed MD5 hash
> > collisions could be practically achieved with some types of data. (or
> > something along those lines)
> 
> I'm aware of MD5 being considered as broken for cryptographic use
> cases, but this one isn't cryptographic so I don't care about the
> problem of crafted collisions here. The only real problem here would
> be when you have two datastores with different mount paths that hash
> to the same UUID, but I think md5 is collision-free enough so we can
> ignore this problem.
> 
> There is another "problem" with the approach of using the mount path
> hash as UUID. In case of a Windows based GSX server you can use CIFS
> shares as datastores addressed via UNC paths like \\nas\share. If you
> have multiple GSX server sharing that datastore then all will have the
> same UUID because the have the same mount path. Actually I don't
> consider this as a real problem because in this case there is one
> datastore with one UUID shared between multiple hosts.

This is actually a feature! If the same storage pool is visible on
multiple hosts, it is absolutely desirable that it have the same
UUID on each host.

> > For all intents and purposes, I'm thinking it'll make no practical
> > functional difference, but figure it's worth asking. :)
> >
> 
> gnulib also provides SHA1 and SHA256 so we could use those instead of
> MD5, but I think MD5 is good enough for this special use case here.

Agreed, we don't need cryptographic security for this use case, so MD5
is fine.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]