Tag: sddl

I am working with a virtual GNU/Linux system, because the machine I’m working with must run a Windows on its bare metal.

I thought I wanted to give raw disk access to the guest, but it turns out, that it is not very easy in Windows to give permanent permissions to a regular user. You can give permissions using the semi-official subinacl like so:
C:\WINDOWS\system32>"C:\Program Files (x86)\Windows Resource Kits\Tools\subinacl.exe" /noverbose /file \\.\physicaldrive1 /display=sddl

I needed to figure out that the language the ACLs are written in, is SDDL and how to give my current useror group all permissions. I failed doing that so I opted for giving all access to every entity known to the system… You can see the relevant SDDL in the listing above.

But that change will only survive until the next reboot. To make the software permanent, an unofficial tool called dskacl can theoretically be used. Apparently it tries to write special values to the Windows Registry. Although I found my way through the documentation, I couldn’t make it work. It actually failed so hard on me that even Windows could not see the drive itself. So make a good contingency plan before even trying to make it work. It’s not really meant for attached disks, but rather external disks via USB. Anyway, I thought I’d have to redo the above mentioned step on every boot.

The question I had was, whether it’s actually worth it. I assumed that it would be a speed up to write directly to the harddrive without having to go through Windows and VirtualBox’ VDI layer before hitting the disk.

So I measured my typical workload: compiling Chromium. As it is what I’m working on, I want compilations to happen as quickly as possible.

I did a handul of runs to compensate for some irregularities that might happen on the host (or in fact, on the guest…)

When writing on an Ext4 straight onto the disk, I get the following results:

real 61m59.895s
user 322m52.832s
sys 46m49.268s

real 61m25.565s
user 318m40.680s
sys 46m7.608s

real 58m59.939s
user 320m36.500s
sys 46m28.336s

Having an Ext4 filesystem in a VDI container on an NTFS partition yields the following results:

real 60m50.360s
user 322m18.184s
sys 47m3.588s

real 57m30.324s
user 318m48.752s
sys 46m52.016s

real 63m29.179s
user 328m55.004s
sys 48m4.692s

I couldn’t test shared folders, because either the NTFS or in fact the vboxfs don’t support operations needed for the compilation. I guess it’s VirtualBoxes fault though…

My interpretation of the results:

Writing directly to the disk seems to be marginally slower than going through the VDI container. At best, there is no significant deviation from writing to the container. I decided that it’s not worth to write straight to disk. Going through the VDI container and through Windows is fine. Especially with all the risks involved such as Windows not being able to see the drive at all.

I acknowledge that my data is a bit flawed. It is likely that you cannot generalise my findings for any other workload. The method is also questionable as I didn’t flush caches or took care of anything disturbing my measurements. If you do measure yourself, I’m interested in getting the results.