[vbox-dev] VirtualBox customized frontend support

[Klaus Espenlaub]

Hi Karoline,

On 21.05.2014 08:29, Karoline Haus wrote:
> Hi Klaus,
>
> Thanks for your reply.
>
> I'm not really building a "random" frontend. After all, it is fully
> built into VBox and it even has a hardened profile. It is also
> integrated into /usr/lib/virtualbox/VBox - I have a fully modified VBox
> source code version to allow this. So you can see this frontend as being
> trusted just as VBoxSDL. (In fact, even more, because it has a much
> smaller code base :-)

If it wouldn't be trusted it wouldn't pass the safeguards we have in 
various places, and thus wouldn't be able to run a VM. Never assumed 
it's "random" code :)

We understand that there are valid reasons for implementing custom 
frontends, and have no intentions of making the life of people who are 
doing this any harder than necessary.

Still, so far we didn't have a good idea to make the list of accepted 
frontends (which figures out the executable name and starts it with the 
appropriate parameters) easier to extend. Changing the method is of 
course possible, yet it's far from the ideal situation, as such patches 
would break if we need to change the code for whatever reason. That's 
why I was mentioning we'd listen to proposals for improving this.

> If I added my frontend in MachineImpl.cpp, would that be sufficient to
> make things work? Or does the SDK have to be modified as well? (I'm
> using the Python API, for connecting to VBox, but I guess that just goes
> through the same hooks as VBoxManage)

This would be sufficient. No other places would need to be adjusted. The 
error you saw comes straight from the final "else" in this method.

Klaus
>
> Thanks for your help,
> Karoline
>
> Klaus Espenlaub <klaus.espenlaub at oracle.com> schrieb am 15:17 Dienstag,
> 20.Mai 2014:
>
>
> Karoline,
>
> On 20.05.2014 07:23, Karoline Haus wrote:
>  > Hi,
>  > I’ve developed a custom VBox graphics frontend, replacing VBoxSDL or
>  > VBoxHeadless. It’s working well when I call it from the command line
>  > using “VBoxMyFrontend –startvm VM” and so on. I have built the frontend
>  > my modifying the VBox source code which I downloaded from the official
>  > website. Here I have added another frontend under src/VBox/Frontends
>  > where I now have a folder VBoxMyFrontend. The compilation works fine and
>  > as I said I can start the frontend as well.
>
> Sounds good so far, everything as expected.
>
>  > Now what does not work is to start the VM using VBoxManage when I try to
>  > set the default frontend of that VM to my own one. Like this:
>  > # VBoxManage modifyvm Test2 --defaultfrontend MyFrontend
>  > # VBoxManage startvm Test2
>  > VBoxManage: error: Invalid frontend name: 'MyFrontend'
>  > VBoxManage: error: Details: code NS_ERROR_INVALID_ARG (0x80070057),
>  > component Machine, interface IMachine, callee nsISupports
>  > VBoxManage: error: Context: "LaunchVMProcess(a->session,
>  > sessionType.raw(), env.raw(), progress.asOutParam())" at line 592 of
>  > file VBoxManageMisc.cpp
>
> Again this is expected behavior... the "defaultfrontend" setting isn't
> sanity checked immediately, but it is matched against a list of known
> frontends which today can't be extended:
> "gui", "GUI/Qt": start VirtualBox
> "sdl", "GUI/SDL": start VBoxSDL
> "headless", "capture", "vrdp": start VBoxHeadless
>
> If you search for those strings in MachineImpl.cpp you'll find the code
> which triggers the launching of a VM process.
>
> Note that this code deliberately doesn't allow starting random
> executables - who knows, someone might manage to construct a security
> issue out of it. Even starting random executables from the VirtualBox
> subdirectory can be used to cause trouble.
>
> That said - if you have a good idea how to make it more flexible without
> completely ignoring the potentially dangerous start of random things,
> let us know. We're interested, for exactly the reason you need it: to
> allow people to implement their own frontends.
>
>  > How can I make this work, and register my frontend with VBoxManage? Is
>  > this possible at all, or would I have to change the VBox API bindings
>  > somewhere?
>
> No support for this yet, as described...
>
> Klaus
>
>  > Any help would be greatly appreciated.
>  > Thanks!