[vbox-dev] UUID's

[James Lucas]

Thanks Guys (Klaus & Dmitry),

I'm writing up a quick tutorial on writing External Auth Plugins and I'll
include both by base64 and LibUUID examples with the pointer to byte swapping
to help people running into this in the future. I still have an issue when my
shared library is unloaded causes a "General Protection Fault" when libuuid is
used, which i'm sure is a simple memory leak.

I'll also try the suggestion of linking to VBoxRT.so which might be an effective
solution to the endian problem. My authorization service matches users against
the string UUID and also talks to the authentication service, so a string
representation is all I need.

- James


Quoting Klaus Espenlaub <Klaus.Espenlaub at Sun.COM>:

> James Lucas wrote:
> > Can someone from VirtualBox/Sun respond? This issue is incredibly 
> > annoying when developing an external authentication plugin.
> 
> Sorry that it took so long to get back to you. Had to ask some people 
> who knew how UUIDs are handled in VirtualBox. Required digging quite a 
> bit though the history. And simple things like your question easily 
> become a difficult
> 
> > I've used two different libraries in two different languages and they 
> > decode the VirtualBox binary string to the same UUID, however this 
> > string differs from the VirtualBox decoded string value.
> > 
> > Tests were:
> > 1) Decode client side using libuuid (as explained previously)
> > 2) Base64 encode value and send to the xmlrpc server. Decoded UUID using 
> > Java java.util.UUID
> 
> I bet libuuid implements "big endian" UUIDs, as defined in RFC4122. Note 
> that this spec is really really recent, and the older ones don't say 
> anything about byte ordering.
> 
> > It appears that the binary representation has the most-significant bits 
> > (first 64 bits) in a different byte order than the other two libraries 
> > are expecting. A work around on server side was easy to implement. To me 
> > this is a bug if the binary storage of the UUID differs from the specs 
> > (which have a section on byte ordering)
> 
> I've looked at the older specs, and it's really the case that VBox is 
> not doing what other people have read into the UUID spec (looked at the 
> DCE spec myself to verify - it leaves the issue of byte ordering 
> completely open). The main problem there is that VirtualBox UUID 
> handling needs to be 100% consistent on Windows, Linux, OSX, Solaris and 
> all other platforms, since the UUID is stored in text form in the xml 
> files, and in binary form e.g. in VDI files. Guess which platform sets 
> the rules for all others.
> 
> So I fear all we can do is to document that you need to byte swap the 
> first 3 uuid parts (one 32bit and after that two 16bit values) to make 
> the VirtualBox UUIDs "big endian" UUIDs as expected by most other 
> libraries. Byte swapping the entire 64bit is not the correct thing to do.
> 
> Any suggestion for an easy to find place in the VirtualBox API 
> documentation?
> 
> 
> Klaus
> 
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> http://vbox.innotek.de/mailman/listinfo/vbox-dev
> 



--
UTS CRICOS Provider Code:  00099F
DISCLAIMER: This email message and any accompanying attachments may contain
confidential information.  If you are not the intended recipient, do not
read, use, disseminate, distribute or copy this message or attachments.  If
you have received this message in error, please notify the sender
immediately and delete this message. Any views expressed in this message
are those of the individual sender, except where the sender expressly, and
with authority, states them to be the views the University of Technology,
Sydney. Before opening any attachments, please check them for viruses and
defects.