VirtualBox: Windows client seeing the Linux host filesystem as a real drive
VirtualBox remains my favorite virtualization solution; it's free, runs everywhere and just does its job real nice - let's hope Oracle doesn't screw this one up as well! Specifically VirtualBox helps me as a developer needing to work in .NET/C#, without having to leave the Linux platform entirely. Let's face it, once you tried the power, freedom and flexibility of a GNU Linux operating system, it is rather hard to go back to the constraints of a Windows box.
However, when working on some .NET code using DirectoryCatalog which is part of the Managed Extensibility Framework (now Microsoft Composition), it became apparent that dynamic linking of assemblies poses certain trouble across a network drive on Windows due to security constraints. I find this a little odd, on the Java platform a network drive mount is considered a first class citizen rather than a special network resource (the whole point of mounting would appear to be to forego the network abstraction in the first place no?), so a normal ClassLoader can do the job and there's no need for a URLClassLoader. In any event, after discovering some related issues when loading assemblies dynamically, it became clear that I had to work around the MEF abstractions and that was *not* the point of using it in the first place.
First of all, you need to have Windows see and mount your shared folder as a network drive. In my case, I let Windows mount it to the next available drive-letter of E.
Then you use the mklink utility in administrator mode, to mount the E:\ drive into a subdirectory of you NTFS partition. In my case I chose to mount my entire "Development" directory into Windows' generic Document's folder. The only way I figured out how to escalate to administrator mode in Windows, is to right-click on a program, so I used notepad to write the mklink command into a batch-file (mount.bat), saved and then ran it as administrator.
Once the script has run, it will have created a folder (a shortcut actually) for you in "Documents". Once you verified this, you may simple delete the mount.bat file, since you won't have to use it again.
In my case I also created a shortcut to the "Development" folder from the desktop, so now it's easy to navigate the rather complex abstraction-chain shortcut -> soft directory-junction -> network-share -> EXT4 filesystem. Deleting the mount point "Development" only has the effect of deleting the directory-junction, nothing on the actual host EXT4 filesystem is deleted.
I am sure Microsoft thought long and hard over their .NET/C# sandbox and associated security model, but this aspect doesn't strike me as particular bullet-proof. After all, if a hacker is able to mount a network drive, he's probably also able to create a directory-junction!
VirtualBox shared folder
VirtualBox has a nice feature, where it can expose a folder from the host operating system, as a network share to the client operating system. This has been an approach I have used in the past as well, in order to still have the powerful Linux command-line available along with common utilities like maven, subversion, diff etc. Remember for this to work, you will have to install the Guest Additions in the virtual image.
However, when working on some .NET code using DirectoryCatalog which is part of the Managed Extensibility Framework (now Microsoft Composition), it became apparent that dynamic linking of assemblies poses certain trouble across a network drive on Windows due to security constraints. I find this a little odd, on the Java platform a network drive mount is considered a first class citizen rather than a special network resource (the whole point of mounting would appear to be to forego the network abstraction in the first place no?), so a normal ClassLoader can do the job and there's no need for a URLClassLoader. In any event, after discovering some related issues when loading assemblies dynamically, it became clear that I had to work around the MEF abstractions and that was *not* the point of using it in the first place.
Fooling Windows
So I though that the only way forward was to fool Windows (and the .NET/C# security model) which would allow me to use the MEF as intended. I tried a bunch of tricks incl. the diskpart, mountvol, netdrive and subst command-line tools but nothing worked. However, then I stumbled upon the mlink tool.First of all, you need to have Windows see and mount your shared folder as a network drive. In my case, I let Windows mount it to the next available drive-letter of E.
Then you use the mklink utility in administrator mode, to mount the E:\ drive into a subdirectory of you NTFS partition. In my case I chose to mount my entire "Development" directory into Windows' generic Document's folder. The only way I figured out how to escalate to administrator mode in Windows, is to right-click on a program, so I used notepad to write the mklink command into a batch-file (mount.bat), saved and then ran it as administrator.
Once the script has run, it will have created a folder (a shortcut actually) for you in "Documents". Once you verified this, you may simple delete the mount.bat file, since you won't have to use it again.
In my case I also created a shortcut to the "Development" folder from the desktop, so now it's easy to navigate the rather complex abstraction-chain shortcut -> soft directory-junction -> network-share -> EXT4 filesystem. Deleting the mount point "Development" only has the effect of deleting the directory-junction, nothing on the actual host EXT4 filesystem is deleted.
I am sure Microsoft thought long and hard over their .NET/C# sandbox and associated security model, but this aspect doesn't strike me as particular bullet-proof. After all, if a hacker is able to mount a network drive, he's probably also able to create a directory-junction!
Comments