-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker-for-win: --vcxsrv: X cookie authentication fails #160
Comments
This is the code of interest:
This is the line that probably fails: https://github.com/mviereck/x11docker/blob/master/x11docker#L3109
Can you please try:
The last output line must start with
|
I am not sure about what to try. I copied the code block to a
Then, I tried
EDIT In the following snippet,
|
And I am a bit confused from your results. :-)
I get the following output and a valid cookie in MSYS2:
Edit: Looking at my output, I see that only one cookie in |
I get an empty output: Cookie is empty, because # ./test.sh
+ rm Xclientcookie
+ export 'PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/c/Program Files/Docker/Docker/resources/bin:/c/Program Files/VcXsrv/'
+ PATH='/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/c/Program Files/Docker/Docker/resources/bin:/c/Program Files/VcXsrv/'
+ rmcr
+ case "${1:-}" in
++ mcookie
++ printf '\r'
+ xauth.exe -v -i -f Xclientcookie add :200 . 5c8c22d5aa7be4e3ad10f72c6459db64
+ sed $'s/\r//g'
C:\Program Files\VcXsrv\xauth.exe: file Xclientcookie does not exist
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
++ xauth.exe -i -f Xclientcookie nlist
++ rmcr
++ case "${1:-}" in
++ sed -e 's/^..../ffff/g'
+++ printf '\r'
++ sed $'s/\r//g'
+ Cookie=
+ echo ''
+ xauth.exe -v -i -f Xclientcookie nmerge -
C:\Program Files\VcXsrv\xauth.exe: (argv):1: unable to read any entries from file "(stdin)"
Ignoring locks on authority file Xclientcookie
+ xauth.exe -f Xclientcookie nlist This is the hexdump of Xclientcookie, in case it helps: # hexdump Xclientcookie
0000000 0600 1000 80fe 0000 0000 0000 60fc b213
0000010 97e1 0d9c 000a 3203 3030 1200 494d 2d54
0000020 414d 4947 2d43 4f43 4b4f 4549 312d 1000
0000030 8c5c d522 7baa e3e4 10ad 2cf7 5964 64db
0000040 0600 1000 80fe 0000 0000 0000 64a4 5bf0
0000050 9ca6 ff7c 0300 3032 0030 4d12 5449 4d2d
0000060 4741 4349 432d 4f4f 494b 2d45 0031 5c10
0000070 228c aad5 e47b ade3 f710 642c db59 0064
0000080 0000 0d04 000a 014b 0300 3032 0030 4d12
0000090 5449 4d2d 4741 4349 432d 4f4f 494b 2d45
00000a0 0031 5c10 228c aad5 e47b ade3 f710 642c
00000b0 db59 0064 0000 c004 01a8 0080 3203 3030
00000c0 1200 494d 2d54 414d 4947 2d43 4f43 4b4f
00000d0 4549 312d 1000 8c5c d522 7baa e3e4 10ad
00000e0 2cf7 5964 64db
00000e6 |
I am completly out of ideas. It just works here. |
I just started a Debian container and installed xauth there. I then tried creating the cookie inside the container ( So, an ugly, but possible workaround is to use xauth inside the container to create the cookie. EDIT Note the difference of size between a cookie created inside the container and the one created outside: # hexdump.exe Xclientcookie
0000000 0001 0c00 3666 6536 6466 6536 3237 3232
0000010 0300 3032 0030 4d12 5449 4d2d 4741 4349
0000020 432d 4f4f 494b 2d45 0031 8310 c98f c677
0000030 824f 236b 2bb0 114f 93f2 0044
000003b |
That is not a way to go. I'd rather drop
Normally |
I'll try to support |
From a user perspective, I think that it is equivalent (or even better) to use a container as a workaround, instead of requiring Cygwin/X. All the users of x11docker have docker installed. Many users do have MSYS2 or Git Bash. With WSL2, even more users will be able to GNU/Linux apps in the Terminal. So, the advantage of VcXsrv is that the user requires a single additional dependency; a very specific tool: an X server. Conversely, by requiring Cygwin/X, users are forced to installing a full new term (Cygwin), which duplicates the functionality already available through MSYS or WSL. Moreover, Cygwin does not have any package manager, so it requires multiple packages to be looked for and selected manually. Unless it is possible to provide a kind of config file to Cygwin in order to automate the installation on multiple dependencies, I think that users which are looking for the most painless solution will prefer VcXsrv with Nonetheless, I think that the underlying issue might be that Therefore, I believe that the way to go is to just add a warning, letting users know that authorization might not work with VcXsrv. Overall, we should suggest Cygwin/X, because of this and because of GPU support. But I would not drop VcXsrv. The code is already written, the 'knowledge' is part of the script, I use it every day, and it works ok until some external update broke it.
Might it be that EDIT
It works. |
You are right. That was the reason why I preferred Now I have two bugs with VcXsrv: broken
I am aware that many users won't care and will just use
From the developer's perspective: I see two ways to simplify the Windows code: WSL is trendy and hip. From a popularity point of view, this would be the best choice. |
Although I do not agree, I understand your point of view.
I don't know if I am missing anything, but generating a cookie in a container would require jsut aliasing a command. I do not feel it to be 'complex'. But I agree that it adds some additional small bit, and you prefer to go the other way.
This sounds slightly contradictory to me. You have stated before that you'd rather drop VcXsrv support instead of providing an unsecure default. However, you are suggesting to use VcXsrv here. Does this mean that
Although I am not a big fan of WSL, I agree. It seems that WSL2 will provide most of the features of MSYS2.
I am not sure about this. I have seen that it will be possible to run the docker daemon in a WSL2 machine/container, which is somehow equivalent to Docker in Docker (dind). I don't know for sure whether it'll be possible to run the daemon on the underlying VM (the one running the linux kernel, where all the containers are executed). If this later approach is possible, docker-for-win itself might not make much sense. Otherwise, I do not think that it will make any difference.
I believe that, at some point, Microsoft will provide a built-in X server, just as they are providing a VM with a Linux kernel and rewriting part of MSYS. At that point, neither VcXsrv nor Cygwin/X will be required. However, I found no reference about this yet. |
Yes. Tools like Things would also become easier if x11docker supports Cygwin/X only, but I assume WSL(2) will supersede it in future.
AFAIK docker will run directly on the WSL2-Linux-Kernel. It is not possible in WSL1 due to missing kernel features (cgroups). There will be no need for the current Docker-VM setup. That might also fix odd bugs like #104.
There has been some requests in the WSL Github tracker, e.g. microsoft/WSL#2356. |
I hope you are correct, but that is not what I understood while watching: https://www.youtube.com/watch?v=lwhMThePdIo. Please see the diagram at min 41:20 and the demo at min 13:00. The docker daemon in the demo is started in 'Ubuntu' which is a container, not the VM. So, there will be no need for the current Docker-VM setup. But the alternative will not be technically equivalent at all.
Thanks for the reference. |
I've looked into the video, but found it a bit confusing. Other than WSL1, WSL2 runs a real Linux kernel. This kernel runs in a VM.
Ubuntu runs directly on the Linux kernel. It is not a container, it is a VM. Docker is started in Ubuntu. There is no docker-in-docker setup.
This is still a sort of VM setup. But x11docker and docker will run in the same WSL2-VM. Currently, the MobyVM only runs docker.
I don't see disadvantages. Probably the current MobyVM will be dropped, but it will still be possible to run For x11docker I see the advantage to have However, maybe WSL2 won't run nested in a Windows VM. I already did not get MobyVM to work. |
I do not think that 'Ubuntu runs directly on the Linux kernel'. When you say 'Ubuntu' I think you mean the shortcut that is shown in the screencast. That is a shortcut to what they call a Right now, there is no explicit VM behind WSL1, so you cannot interact with it. They say that:
Which leads me to think that the VM will be a black box, just as the Moby-WM. The difference is that docker is automatically started in Moby-VM, which I don't know if it will be possible in Microsoft's VM. However, WSL2 distros are not OCI containers, because the target of Microsoft is to be able to execute GNU/Linux tools seamlessly, so they break almost every isolation possible. Hence, it might make sense to execute the docker daemon in a WSL2 distro, provided that the isolation between the distro and the VM is nearly inexistent. AFAIK, Microsoft is doing this in partnership with Docker, not on their own. Therefore, if they decided to go this way, it must be because there is no relevant performance issue. Furthermore, it is interesting, since it allows to start different docker daemons in several WSL2 distros. And this is precisely the context that I wanted to bring. This is not possible with docker-for-win/WSL1 but I think that it will be an option with WSL2.
This is what I am not sure about. I think that x11docker and docker will run in the same WSL2 distro, which will be executed on a VM. But neither x11docker nor docker will run on the VM directly. There seems that there is no explicit mechanism to get a shell in the VM.
I'm quite sure about it. How will it work, tho? If a single docker daemon is started on a WSL2 distro, it might be possible that it is listening on a default port, which is automatically bind to the VM, and the host (Windows). Any other daemon started in a different WSL2 distro will likely conflict. Overall, I find it great to let the user configure the docker daemon as in a GNU/Linux environment, instead of being constrained by the configuration of the daemon in the Moby-WM. However, with great power comes great responsibility.
Yes, I think that the codebase will be simplified a lot with WSL2. Support for MSYS2 could be dropped right away. I am not sure about Cygwin/X, tho. GPU support is an interesting feature to have.
I agree. WSL2 will require Hyper-V. That's why they will keep WSL1: for users without Hyper-V. |
Whatever the technical details will be indeed - I am currently thinking about some sort of political dimension. I've been curious already why there was and is no X suppot for WSL. It is an easy task to provide e.g. VcXsrv in WSL. Microsoft could just do it with almost no effort. There has been several user requests, but they all has been refused. Maybe Microsoft just dont want it. It would allow the "common GUI user" some Linux experience. Currently only Linux nerds will use WSL. But with a WSL GUI environment many less geeky Windows users could try and like Linux. They could say, Linux is cool, let us use Linux natively and drop Windows at all. Speaking from me, I am not really happy to support Microsoft. They did a bad lobbywork in Germany a few years ago and killed the Limux project. The city Munich/München switched from Windows to Linux several years ago. After some struggling it got stable and was a famous prestige project. I am angry. I think of:
These thoughts are not technical at all, though. I would like to hear your thoughts about this. |
I must agree with you on almost everything. They also did bad lobbywork around here for several years, and they are still doing it, specially targeting education. I am aware about the case of Munich too. It was such a sad new.
I think that this might be incoherent. Although I would prefer having Cygwin support rather than not having support at all, I think that it is not consistent to support Cygwin and not WSL. Both are solutions to use GNU/Linux tools on Microsoft's Windows. Both of them rely on some free, other open, and other closed source pieces of software. The difference between them is mostly technological. I.e., if someone was to write a HyperV-based Cygwin today, the architecture would probably look quite similar to WSL. Moreover, both installing and using Cygwin is harder than either WSL or GNU/Linux. A common GUI user which needs to start using terminal apps might be confused about WSL being much easier, and it might lead to thinking that Microsoft's Linux is easier than a regular GNU/Linux. I think that, from a strategic point of view, it is better to let new users mix windows and linux binaries almost seamlessly. Hopefully, at one point they will be using all linux binaries without even realizing about it.
I think that x11docker can signifficantly help in this sense. According to the demos, it will be possible to launch a windows GUI app from WSL. So, users might feel that Linux is not for regular apps, because GUIs only work on windows. A simple script (which calls x11docker, or an independent one) sourced in I also think that the Windows part of the codebase is getting too complex, so I agree with you when you point out that in a few months a single and straighforward solution should be kept. At the same time, the main reason for me to switch from my own script to x11docker was Windows support. On GNU/Linux, it is straighforward to share the X server on the host with any docker container. Hence, it is easy to set up, even by hand. However, on Windows it is not so easy. Therefore, if Windows support was dropped, I would probably need to stick with the current version. For me, it is prioritary to have a common syntax on both platforms, because it allows me to write all the scripts and development assets once. I could wrap x11docker with my own 'entrypoint', which I did in the past; but this would imply that I would not use any x11docker feature which I am not able to replicate on Windows on my own. In the end, it is going to be mostly your time and effort, so I completely understand if you do not want to support Microsoft at all, be it because you are angry or because of any other reason. |
Thank you for your thoughts. You have said some important points to consider. As a start, I have published runx v0.1. It can also be used for x11docker in future. This will allow me to drop some Windows code from x11docker. I want to support x11docker in at least WSL. |
Thanks to you for making an open dicussion about it ;). I find your solution very sensible. I tried runx in WSL and I can confirm that it works. Awesome! Just two minor issues:
|
Thanks. :-) Let's continue this in #165. |
Coming from #145 (comment)
@1138-4eb wrote:
The text was updated successfully, but these errors were encountered: