I remember back in 2016 when Microsoft announced the Windows Subsystem for Linux, I was super-excited to try this new feature. At the time I was working on Linux daily but only for pretty basic stuff, yet it was still stuff that Windows made difficult. Tools like grep, wget, ssh and nc required a whole VM to be running elsewhere on my machine.

So when Microsoft announced that they’ll be throwing some sort of virtualised\emulated\native\whatever Linux kernel into Windows, I was curiously optimistic.

Well, along came the first release and boy did it suck.

I promptly forgot about the feature for a few more years until recently, when after temporarily trashing my virtual machine environment, I was left without immediate access to Linux. A thought occurred to give WSL another shot since development had been consistent and I was curious how far it had come.

Well, I’m glad I did give it another try, because the second time around WSL had proven its come a long way and was a much more pleasant experience. Not only was installation quick and easy, but all the basics were there, complete with native package management and a shared filesystem. I decided to dig deeper into WSL2.

Easy Hosting

For starters, Microsoft have enabled installation via the Microsoft Store. Just search for “Linux” within the Microsoft Store (how weird does that sound?!) to find a list of various distributions that have been made available, along with complete packages. Furthermore, once you have chosen your distro of choice, and installed Linux – The kernel is updated and maintained by Windows Update!

Alternatively, PowerShell now includes an easy installer wsl --install.

The following distro’s are available as of writing:

• Ubuntu
• Debian GNU/Linux
• Kali Linux Rolling
• openSUSE Leap 42
• SUSE Linux Enterprise Server v12
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Ubuntu 20.04 LTS

Once installed, Windows takes care of creating your first username\password, complete with sudo privileges. You’ll now be able to launch WSL from the Start Menu or Windows Terminal. The shell you’re now running isn’t virtualised, it’s running native Linux binaries including Bash. Microsoft have built a layer into the Windows Kernel to hook into the Linux kernel and intercept calls, translating them into Windows API calls instead. The benefit being performance, and no need to rewrite Linux programs. The native ones will (mostly) work just fine.

There’s a couple of key points to note when running Linux within Windows:

• Windows users can’t share a Linux installation
• Usernames\passwords aren’t shared across multiple Linux installations
• Linux maintains its own filesystem, but with direct access to your Windows NFTS drives

Permissions

Two major differences between Windows and Linux are the filesystem and permissions. So how does WSL reconcile these features across two very different platforms? The answer has been well thought out by the nerds over as Microsoft HQ.

Permissions can be handled either by adding metadata to Windows based NTFS files, which explicitly give files user\group and access permissions, or by interpreting Windows permissions into Linux automatically. Files within NTFS are typically just assigned the WSL user as owner.

The metadata that WSL supports for each Windows based file is as follows:

Attribute Name	Description
$LXUID	User Owner ID
$LXGID	Group Owner ID
$LXMOD	File mode (File systems permission octals and type, e.g: 0777)
$LXDEV	Device, if it is a device file

Adding the fields above will result in WSL reading permissions as defined by you, rather than guessing based on Windows permissions (which pretty much gets it right most of the time anyway).