Peculiar Permissions

Other peculiarities await. All files below /mnt/c belong to root. Changes to user rights with chmod and chown are ineffective. This handicap does not seriously disrupt usability, however, because you can freely create and delete files and directories in your subsystem.

However, if you want to transfer user rights for files during a data transfer, it has to be set up during or after the transfer. Rsync offers a solution for this:

rsync --perms --chmod=+wrx,go-w index.html server:/var/www

The perms parameter makes sure that the synchronization tool also transfers the directory rights. In the first step, chmod sets all rights for the user, the owner group, and everyone else using +wrx. In the second step, the go-w expression deprives the group and others of write permissions. In this way, the transferred file (here, index.html) receives the rwxr-xr-x permissions. Incidentally, Rsync uses filters to distinguish between directories (D) and files (F). An additional F-x expression as the third element in the comma-separated list would eliminate the ability of all files to be executed.

If you would prefer to use your own SSH key, the script in Listing 1 backs up the SSH key and config files from your home directory into the /etc/ssh folder. If you do without the script, calling the ssh myserver command throws up the Bad owner or permissions on /mnt/c/users/<pa>/.ssh/config error message.

01 #!/bin/bash
02 cd ~
03 if [ -d .ssh ]; then
04   tar cf ssh.tar .ssh
05   for keyfile in `grep -le 'BEGIN .* PRIVATE KEY' -e '^ssh-' .ssh/*`; do
06     filename=`filename $keyfile`
07     mv $keyfile /etc/ssh
08     chmod 644 /etc/ssh/$filename
09   done
10   if [ -f .ssh/config ]; then
11     cat .ssh/config >> /etc/ssh/ssh_config
12     sed -i 's|~/.ssh|/etc/ssh|g' /etc/ssh/ssh_config
13     rm -f .ssh/config
14   fi
15 fi

At the end, back up Listing 1 as the file ssh-extend.sh and call it – also in the shell – with the sudo bash ssh-extend.sh command. In line 2, the script initially switches to the home of the user. If any content exists in the ~/.ssh folder, line 4 saves it using the tar archive command. The for loop iterates over all the files that the grep expression identifies as key files.

The character strings after the -e switch work as regular search patterns. Line 7 moves a key file to /etc/ssh each loop run; line 8 sets appropriate access rights.

Assuming ~/.ssh/config is available, the script transfers the settings of this configuration file into the global SSH configuration file. In line 11, the script attaches the found entries to the end of the /etc/ssh/ssh_config file using the >> operator. The sed command then uses search and replace to replace the ~/.ssh path prefix with /etc/ssh. Because the Linux subsystem is in the Windows users directory, there is no threat of a breach of security from the transfer of key files in the subsystem. SSH can then be used in the shell as usual.

Nuclear Fission

The limitations of the subsystem should be a lot greater for programs that have access to kernel features, because the Linux subsystem has to make do without the Linux kernel. However, Linux processes run in a new process type called Pico [3] in the Windows user space (Figure 4). Windows translates kernel calls from the Pico process through Pico providers Lxss and LxCore into calls to the Windows kernel and forwards them transparently.

Figure 4: Pico processes take a route for kernel calls different from native Windows processes.

You can check how well this works with the Docker container solution. Similar to Cygwin, the Creators Update makes it possible to call .exe files from the Shell. If you install Docker under Windows and .bashrc in the home directory and then add the Bash code from Listing 2, the Docker commands can be used after restarting the shell, as in Linux. The for loop frees all .exe files from their file extensions and connects them to the Linux world with an alias.

DOCKER_BIN='/mnt/c/Program Files/Docker/Docker/resources/bin'
for f in "$DOCKER_BIN"/*; do
  alias "$(basename "$f" | sed 's/.exe$//')" '="'"$f"'"'
done

Only the interactive terminal mode (option -t, as in the docker run -it debian bash command) fails, because Bash cannot interpret the Windows terminal protocol. Creating an appropriate pseudo-terminal with

sudo /sbin/MAKEDV -v pty

also failed in the test. Under Cygwin, the winpty command helps achieve the desired result [4].

What a Shame: Paths

Windows and Linux use different path schemes to address resources within their directory tree. With Subversion, for example, you can check a working copy of the repository document with the file:///C/Users/<pa>/svn/documents Windows path.

However, a subsequent attempt to update the working copy with the svn update Bash command fails, because Linux cannot cope with the source path.

This class of issues is sometimes fixed with a diversion into the network world, because Linux and Windows analyze URLs in the same way. Under Subversion, the command

sc create svnserve binpath= "\"C:\Program Files\TortoiseSVN\bin\svnserve.exe\" --service -r C:\User\<pa>\svn" displayname= "Subversion Server" depend= Tcpip start= auto

entered with administrative privileges initially registers the internal svnserve server as a Windows service. The sc start svnserve command starts the service; then, check out a working copy by URL:

svn checkout svn://localhost/documents

This time, Subversion is working in both worlds.

Be aware that to write data, you need to add the anon-access = write line to the conf/svnserve.conf file in the root directory of the C:\User\<pa>\svn repository.