search

mviereck / x11docker

Run GUI applications and desktops in docker and podman containers. Focus on security.
MIT License
5.62k stars 378 forks source link

Container isolation check with x11docker/check #145

Closed mviereck closed 5 years ago

mviereck commented 5 years ago

I am currently developing image x11docker/check to check container security. Try out e.g. x11docker --hostdisplay --gpu x11docker/check.

Checking and demonstrating X security leaks already works pretty well.

To improve: I'd like to demonstrate issues with degraded container isolation, e.g. with options --hostnet and --hostipc.

If someone has ideas on how to demonstrate abuse of those setups, please tell me!

eine commented 5 years ago

@mviereck, I found that the interface of x11docker/check can be successfully executed on Win10 with vcxsrv. However when clicking on some of the buttons to run some of the tests, both the GUI and vcxsrv freeze or crash. Are these tests expected to be used on Win10?

mviereck commented 5 years ago

Are these tests expected to be used on Win10?

Yes, I am surprised to hear from crashes. Basically the GUI ist just a regular GUI as arbitrary other ones, too. It uses kaptain similar to x11docker-gui. The checks it provides are not dirty hacks, they just show "official" leaks. Do all buttons lead to a crash? Does it make a difference if you run with option --gpu?

Could you try to run a terminal instead of the GUI?

x11docker x11docker/check xfce4-terminal

You can run the GUI itself with command containercheck.kaptn. Some checks are scripts collected in /opt/bin:

$ ls /opt/bin/
capcheck          formatc    networkinfo  showoutput    windowlist
clipboard         jumpxeyes  palinopsia   soundcheck-alsa
containercheck.kaptn  keylogger  showipc      soundcheck-pulse

A special one is showoutput that shows the output of many checks in mousepad. Maybe that one somehow causes the crash. Please try e.g. showoutput ls -la or showoutput capcheck. Try to run mousepad directly.

On a complete tangent: Microsoft announces a new WSL2 that should be able to run Docker natively without the current MobyVM workaround.

eine commented 5 years ago

Yes, I am surprised to hear from crashes. Basically the GUI ist just a regular GUI as arbitrary other ones, too. It uses kaptain similar to x11docker-gui.

The GUI works ok. But some of the tests make the X server freeze, so the GUI freezes too.

The checks it provides are not dirty hacks, they just show "official" leaks. Do all buttons lead to a crash?

Most of the 'X server security checks' are missing some dependency or do nothing, but they don't crash. See below.

Does it make a difference if you run with option --gpu?

I am running x11docker --clipboard --hostdisplay --gpu x11docker/check.

After running all the tests one by one (see below):

X server security checks

Running a keylogger with 'xinput test'.
In a well isolated case, keypresses should be visible only if container windows have focus, but not if host windows have focus.
If no keypresses are shown while pressing keys although a container window has focus, the check itself failed.

However, I think that the check itself fails.

Trying to run a terminal on host sending keystrokes like ALT+F2 with xdotool.
This is only possible with x11docker option --hostdisplay along with --clipboard or --gpu.
The widespread solution to run GUI applications in Docker with just sharing /tmp/.X11-unix open a security leak here.
Error messages about missing XTEST extension indicate that the X server
does not run with extension XTEST that would allow some X security leaks.

Warning: XTEST extension unavailable on '(null)'. Some functionality may be disabled; See 'man xdotool' for more info.
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Warning: XTEST extension unavailable on '(null)'. Some functionality may be disabled; See 'man xdotool' for more info.
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
Xlib:  extension "XTEST" missing on display "10.0.75.1:101".
....

> NOTE: should it be 'accessible'?

Showing the clipboard content of X server 10.0.75.1:101
If clipboard is shared e.g. with x11docker option --clipboard, you'll see the content of the host clipboard.
(Graphical clips are not regarded yes.)

$ xclip -selection clipboard -o
CONTENT_OF_THE_CLIPBOARD

$ xclip -selection primary -o

$ xclip -selection secondary -o

GPU video memory leak

On the laptop, the gears are shown in the black square, and they seem to "move" for a couple of frames before freezing and crashing.

Polygons in scene: 62464 (64 spheres * 1024 polys/spheres)
Visual ID of window: 0x2c1
Cont

It needs to be terminated.

On the laptop, the demo works successfully.

On the laptop, this is successfull.

Container capabilities

Hardware

On the laptop, this works ok.

ALSA: aplay -l
aplay: device_list:272: no soundcard found...

aplay: device_list:272: no soundcard found...

But it does neither freeze nor crash.

Pulseaudio: $ pactl info
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

$ paply -v /usr/share/games/xboard/sounds/cymbal.wav
Opening a playback stream with sample specification 's161e 1ch 11025Hz' and channel map 'mono'.
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

It does neither freeze nor crash.

Can't open "/dev/video0" as VideoDevice!: No such file or directory
Fatal Error (non-daemon), exiting...
There was no map allocated to be freed...
feh WARNING /tmp/feh_stdin_PEJAir - No Imlib2 loader for that file format
feh: No loadable images specified.
See 'man feh' for detailed usage information

It does neither freeze nor crash.

lpstat: Bad file descriptor
lpstat: Bad file descriptor
no system default destination
eine commented 5 years ago

Could you try to run a terminal instead of the GUI?

x11docker x11docker/check xfce4-terminal

I'm using x11docker --hostdisplay --gpu --display 101 x11docker/check xfce4-terminal now.

NOTE: the clipboard is not shared.

You can run the GUI itself with command containercheck.kaptn.

This works.

Some checks are scripts collected in /opt/bin:

$ ls /opt/bin/
capcheck        formatc    networkinfo  showoutput    windowlist
clipboard       jumpxeyes  palinopsia   soundcheck-alsa
containercheck.kaptn  keylogger  showipc      soundcheck-pulse

This is quite surprising:

eine@33ddcdbab9d2:~$ ls /opt/bin
capcheck   containercheck.kapt  keylogger   soundcheck-alsa   windowlist
clipboard  formatc              palinopsia  soundcheck-pulse

So, networkinfo, showoutput, jumpxeyes and showpic are missing.

On a complete tangent: Microsoft announces a new WSL2 that should be able to run Docker natively without the current MobyVM workaround.

Yes, I was told about it. I have to see this video yet: https://www.youtube.com/watch?v=lwhMThePdIo

EDIT

Upon further inspection, these are not available in the repo where sources or the image are located: https://github.com/mviereck/dockerfile-x11docker-check/tree/master/bin. @mviereck, did you forget to 'git add' them and/or to push the changes to the repo?

mviereck commented 5 years ago

Thanks for your tests! Let us focus on one core issue first:

So, networkinfo, showoutput, jumpxeyes and showpic are missing. did you forget to 'git add' them and/or to push the changes to the repo?

I tried the following, but showoutput is not uploaded to the online repository:

lauscher@buster:~/git/dockerfile-x11docker-check$ git add bin
lauscher@buster:~/git/dockerfile-x11docker-check$ git add bin/showoutput 
lauscher@buster:~/git/dockerfile-x11docker-check$ git push
Username for 'https://github.com': mviereck
Password for 'https://mviereck@github.com': 
Everything up-to-date

git add does not say anything, and git push reports success. But there is no upload. Do I miss something? I am not really familar with the git commands.

eine commented 5 years ago

You need to first git add all/each of the files you want to upload. Then you git commit -m "a commit message" to 'save' all those 'added' files as a commit. Last, you git push the new commit to the remote.

EDIT

If you did git add but not git commit, executing git status will show the added files in green and it will suggest you to git commit. Isn't it?

mviereck commented 5 years ago

Thanks, the git commit part was missing! I did git commit before seeing your git status recommendation. However, the files are online now, and the docker image on docker hub is rebuilding yet.

eine commented 5 years ago

Great. I run the tests again and I updated the comment above.

mviereck commented 5 years ago

'Run keylogger with xinput': an xterm is opened (keylogger@bca3f4c51be0), but nothing happens.

Could you please run xinput in the container terminal and show me the output?

NOTE: should it be 'accessible'?

Fixed, thanks.

I suggest disabling 'Sound' and 'Webcam' checks if x11docker was not executed with the required flags.

I want this image to be usable for setups without x11docker, too. Also, ALSA sound and webcam would work, too, if one provides e.g. --privileged.

However, overall there should be some explanation in each output what results can be expected and how to interpret them. That will help to check off some of the open items. Sometimes a failure message is sort of success -> isolation works. I'll improve the output messages.

Crashes are related to GPU and/or Hardware information.

It is unfortunate that they crash and freeze instead of just failing. Maybe I have to disable them on Windows. However, how should the container know that it runs on Windows? I'll think about it.

Great. I run the tests again and I updated the comment above.

Much thanks for your extensive testing!

eine commented 5 years ago

Could you please run xinput in the container terminal and show me the output?

As commented above, it is a bit annoying that the clipboard seems not to be shared. I took a screenshot instead:

xinput

I want this image to be usable for setups without x11docker, too. Also, ALSA sound and webcam would work, too, if one provides e.g. --privileged.

Gotcha.

I tried:

# ./x11docker --privileged --hostdisplay --gpu x11docker/check xfce4-terminal

x11docker ERROR: x11docker: unknown option -- privileged

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be:
  Please report issues at https://github.com/mviereck/x11docker

If I use x11docker --hostdisplay --gpu -- --privileged -- x11docker/check xfce4-terminal it is successfully started. But the tests (ALSA, Pulseaudio, Webcam and/or CUPS) produce the same output as commented above.

However, overall there should be some explanation in each output what results can be expected and how to interpret them. That will help to check off some of the open items.

This is a great idea.

Crashes are related to GPU and/or Hardware information.

It is unfortunate that they crash and freeze instead of just failing. Maybe I have to disable them on Windows. However, how should the container know that it runs on Windows? I'll think about it.

I think that we might need to revisit #148. I now tried x11docker --gpu -- x11docker/xfce xfce4-terminal, which will open a terminal successfully. When I execute glxinfo in there, I get name of display: 10.0.75.1:101 and it freezes/crashes. I believe that the 'one confirmation' that you mentioned here is me, isn't it? If so, we should consider that we have no valid confirmation now. Note that I am running these tests in a different machine from the one used in #70. That was a laptop with Intel + NVIDIA, and this is a workstation with NVIDIA.

Much thanks for your extensive testing!

You are very welcome.

EDIT

I have checked glxinfo on the laptop again, and it works. So there is some problem with GPU support on my workstation. This is hopefully not a problem with the x11docker/check.

eine commented 5 years ago

I now tried with --clipboard and it works. I also show that you added some messages to explain the expected behaviour of the tests.

I run all the checks on my laptop too. I updated the comment above accordingly. It is surprising for me that glxinfo, glxspheres and hardinfo are successfully executed, but palinopsia and glxgears crash.

mviereck commented 5 years ago

If I use x11docker --hostdisplay --gpu -- --privileged -- x11docker/check xfce4-terminal it is successfully started. But the tests (ALSA, Pulseaudio, Webcam and/or CUPS) produce the same output as commented above.

ALSA and webcam check work here with --privileged. On Linux only, though, on Windows they don't work at all. Pulseaudio and CUPS need more setup than --privileged.

Run keylogger with xinput': an xterm is opened (keylogger@bca3f4c51be0) and a couple of messages are shown explaining the expected behaviour:

Running a keylogger with 'xinput test'. However, I think that the check itself fails.

Your xinput screenshot shows a Windows keyboard. I've added it to the script. It will be interesting if the check shows all keypresses or only those within the VcXsrv windows.

'Try to run a terminal on host with xdotool': another xterm is opened (formatc@bca3f4c51be0) and the following messages are shown:

The message now explains that XTEST errors indicate that the isolation works.

I think that we might need to revisit #148.

Yes, let's discuss Windows GPU issues there to keep this ticket clean. I assume the differences beween your host machines are issues related to VcXsrv. Maybe the GPU checks do not crash with software rendering, i.e. running without option --gpu.

Crashes are related to GPU and/or Hardware information.

I am a bit surprised that hardinfo crashes, too. Maybe it is GPU related? Does it fail, too, if you run without option --gpu?

[ALSA, pulseaudio, printer]

I've updated the messages to explain errors. Some other items still need some explaining messages, I am working on it.

eine commented 5 years ago

ALSA and webcam check work here with --privileged. On Linux only, though, on Windows they don't work at all. Pulseaudio and CUPS need more setup than --privileged.

When x11docker is used to start the container, it should be possible to set some envvar to let the GUI know that those checks are not available. It is not an ideal solution, but it can useful to offer a better first UX until a better solution is found.

Your xinput screenshot shows a Windows keyboard. I've added it to the script. It will be interesting if the check shows all keypresses or only those within the VcXsrv windows.

It shows all the keypresses in any window within the same X server, but not in a different X server or on the host.

Yes, let's discuss Windows GPU issues there to keep this ticket clean. I assume the differences beween your host machines are issues related to VcXsrv. Maybe the GPU checks do not crash with software rendering, i.e. running without option --gpu.

As you say, all of the tests work with software rendering. This is the output of glxinfo:

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.3.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 18.3.4
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

glxgears works at 440-480 FPS and glxspheres at 20-25 FPS.

I am a bit surprised that hardinfo crashes, too. Maybe it is GPU related?

I'm pretty sure that it is related to the GPU. On the laptop, hardinfo works OK and I could even run the benchmnarks (both for CPU and GPU). BTW, it is a very interesting feature that you decided to include this. Thank you.

Does it fail, too, if you run without option --gpu?

No. With software rendering hardinfo works ok.

Some other items still need some explaining messages, I am working on it.

Let me know if you want me to do any further test.

mviereck commented 5 years ago

When x11docker is used to start the container, it should be possible to set some envvar to let the GUI know that those checks are not available. It is not an ideal solution, but it can useful to offer a better first UX until a better solution is found.

Currently I've integrated warning messages in the GUI of x11docker/check. Maybe I could check the output of xinput for Windows to generate dynamic content. However, that will need a dynamic creation of containercheck.kaptn. Currently it is a rather simple static file.

I'm pretty sure that it is related to the GPU. On the laptop, hardinfo works OK and I could even run the benchmnarks (both for CPU and GPU). BTW, it is a very interesting feature that you decided to include this.

Yes, it is quite interesting to see what is visible from the host.

Let me know if you want me to do any further test.

Could you please check --pulseaudio on Windows? (Needs Cygwin with pulseaudio installed, but works for MSYS2 and WSL, too.)

Overall, I've changed nearly all output comments of all check buttons. Could you have a look if they are comprehensive? Especially the glxinfo button should be more useful now.

eine commented 5 years ago

Could you please check --pulseaudio on Windows? (Needs Cygwin with pulseaudio installed, but works for MSYS2 and WSL, too.)

On my workstation, cygwin is not installed at C:/ but at F:/. x11docker fails because of this: 

x11docker WARNING: --pulseaudio: Did not find C:/cygwin64/bin/pulseaudio.exe.
  Please install Cygwin with pulseaudio.
  Fallback: Disabling option --pulseaudio

At the same time, the following message is shown:

x11docker note: Option --pulseaudio: Pulseaudio daemon will continue
  to run after x11docker terminates. You can kill pulseaudio manually with:
      taskkill.exe /PID pulseaudio.exe /F

taskkill.exe /PID pulseaudio.exe /F works on the windows cmd but it is not valid syntax for MSYS2.

Overall, I've changed nearly all output comments of all check buttons. Could you have a look if they are comprehensive? Especially the glxinfo button should be more useful now.

Note that I am neither a native english speaker. It'd be great if any british/american could have a better look. Overall, I'd try to build full sentences. So, for example:

'X server security check': These tests allow to check some possible security leaks in an X window server. Most of them are of interest when x11docker option '--hostdisplay' is used, especially along with '--clipboard' or '--gpu'. However, the widespread setup to share an X server with a docker container through '-v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY' might be affected too.

'Palinopsia leak' With x11docker option --gpu, a privaly leak is possible, which allows former sensitive video content (e.g. letters or 'pron') to be viewed. The content can even survive a reboot. This is because some GPU drivers do not clean the video memory after an application allocates it. See https://hsmr.cc/palinopsia. Error messages or all black window content accross scrolled view indicate that the video memory is not leaked.

Docker allows a subset of capabilities per by default.

About the message in 'Mouse events', it is OK. But it made me realize that isolation does not work. The mouse is followed no matter where it is. The same applies to 'Watch window event with xev': I can see all the events.

'Show some network information with netstat' needs some seconds to execute. This can be misleading, since the user might click multiple times thinking that the first click was not valid.

mviereck commented 5 years ago

On my workstation, cygwin is not installed at C:/ but at F:/. x11docker fails because of this:

Should be fixed now. x11docker looks at drives C ... O.

taskkill.exe /PID pulseaudio.exe /F works on the windows cmd but it is not valid syntax for MSYS2.

I've changed the message that it mentions cmd.exe. However, this one should work to disable MSYS2 path conversion:

env MSYS2_ARG_CONV_EXCL='*'  taskkill.exe /PID pulseaudio.exe /F

x11docker does not do this itself because it uses the same pulseaudio daemon for multiple x11docker containers.

Note that I am neither a native english speaker. It'd be great if any british/american could have a better look. Overall, I'd try to build full sentences. So, for example:

Thanks for the suggestions! I'll look later.

eine commented 5 years ago

On my workstation, cygwin is not installed at C:/ but at F:/. x11docker fails because of this:

Should be fixed now. x11docker looks at drives C ... O.

It does find pulseaudio now. After I try to use it, I can see a process and kill it:

> taskkill.exe /PID pulseaudio.exe /F
SUCCESS: The process "pulseaudio.exe" with PID 21356 has been terminated.

However, the check does not work:

Sound check for pulseaudio sound. (Option --pulseaudio)

You should hear some noise.
Error messages indicate that no pulseaudio connection has been set up.

***************************************************
$ pactl info
Connection failure: Connection refused

***************************************************
$ paplay -v /usr/share/games/xboard/sounds/cymbal.wav
Opening a playback stream with sample specification 's16le 1ch 11025Hz' and channel map 'mono'.
Connection failure: Connection refused

I tried both x11docker --clipboard --pulseaudio x11docker/check and x11docker --clipboard --pulseaudio -- --privileged -- x11docker/check.

mviereck commented 5 years ago

I tried both x11docker --clipboard --pulseaudio x11docker/check and x11docker --clipboard --pulseaudio -- --privileged -- x11docker/check.

--privileged cannot make a difference here. I assume it is a firewall issue once more. On Windows x11docker sets up a pulseaudio connection over TCP because sharing a unix socket is not possible. You can explicitly set --pulseaudio=tcp in further checks to make sure x11docker uses TCP. Could you have a look at your firewall?

Edit:

About the message in 'Mouse events', it is OK. But it made me realize that isolation does not work. The mouse is followed no matter where it is.

Interesting. On Linux all X server options (except --hostdisplay) show mouse cursor movement only on container X server windows. However, it don't think that it is a great issue that VcXsrv behaves different. I've changed the description to "Mouse cursor isolation works if ..." to make clear it does not break isolation overall.

The same applies to 'Watch window event with xev': I can see all the events.

On Linux this could only be the case with --hostdisplay. On Windows it can only be the case for Windows from the X server, not for Windows-windows.

'Show some network information with netstat' needs some seconds to execute. This can be misleading, since the user might click multiple times thinking that the first click was not valid.

That is fast here. Maybe on Windows there is some delay in DNS resolving or something similar. I'm not sure if I should do something here. Maybe a note in the GUI that it takes some time on Windows?

eine commented 5 years ago

I assume it is a firewall issue once more. On Windows x11docker sets up a pulseaudio connection over TCP because sharing a unix socket is not possible. You can explicitly set --pulseaudio=tcp in further checks to make sure x11docker uses TCP. Could you have a look at your firewall?

I used --pulseaudio=tcp and I disabled the firewall. Still the same result.

On Linux this could only be the case with --hostdisplay. On Windows it can only be the case for Windows from the X server, not for Windows-windows.

This might be because the X server has a transparent background window that takes all the available space.

'Show some network information with netstat' needs some seconds to execute. This can be misleading, since the user might click multiple times thinking that the first click was not valid.

That is fast here. Maybe on Windows there is some delay in DNS resolving or something similar. I'm not sure if I should do something here. Maybe a note in the GUI that it takes some time on Windows?

Yes, it is likely to be because of multiple additional intermediate layers. A note will do it.

mviereck commented 5 years ago

I used --pulseaudio=tcp and I disabled the firewall. Still the same result.

I have added a button to run pavucontrol. Maybe the sound is just muted. Could you try again please, still having an eye on the firewall? Could you try in Cygwin as well?

eine commented 5 years ago

Today Win10 restarted after some update. Now, there seems to be some permission problem, and no GUI can be used at all:

# ./x11docker x11docker/check
x11docker note: Failed to check for sshd. ps -p not supported.

x11docker note: Using X server option --vcxsrv

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

x11docker note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings. Compare issue #108 on github.

x11docker note: Your docker version does not support option --group-add.
  Possible sound or GPU setup may fail. Please update your docker installation.

cat: /etc/group: No such file or directory
cat: /etc/group: No such file or directory
cat: /etc/group: No such file or directory
cat: /etc/group: No such file or directory
Authorization required, but no authorization protocol specified
kaptain: cannot connect to X server 10.0.75.1:100

No matter which image I use, I always get Authorization required, but no authorization protocol specified.

mviereck commented 5 years ago

No matter which image I use, I always get Authorization required, but no authorization protocol specified.

It seems I somehow messed up XAUTHORITY, I'll look at that. Meanwhile it should work to run with option --no-auth.

eine commented 5 years ago

It seems I somehow messed up XAUTHORITY, I'll look at that. Meanwhile it should work to run with option --no-auth.

Yes, it works with --no-auth.

When I don't use it (x11docker --verbose x11docker/check), the following error is shown:

LoadPreferences: C:\msys64\home\eine\.XWinrc not found
LoadPreferences: Loading C:\Program Files\VcXsrv\system.XWinrc
Warning: Locale not supported by X, falling back to 'C' locale.
(II) IGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
/c/Users/eine/x11docker/cache/x11docker-check-c01f93/xinitrc: line 107: xsetroot: command not found
-rw-r--r-- 1 eine None 0 May 17 04:47 /c/Users/eine/x11docker/cache/x11docker-check-c01f93/share/Xclientcookie
Failed to retrieve trusted cookie from X server. Will bake one myself.
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
-rw-r--r-- 1 eine None 230 May 17 04:47 /c/Users/eine/x11docker/cache/x11docker-check-c01f93/share/Xclientcookie
C:\Program Files\VcXsrv\xauth.exe: (argv):1:  unable to read any entries from file "(stdin)"
Ignoring locks on authority file Xclientcookie

==> /c/Users/eine/x11docker/cache/x11docker-check-c01f93/message.log <==
x11docker[258.42]: Waiting since 1s for --vcxsrv to be ready.

I think that unable to read any entries from file "(stdin)" might be familiar to you.

I have added a button to run pavucontrol. Maybe the sound is just muted. Could you try again please, still having an eye on the firewall?

Still the same result. When I try to start pavucontrol a window is shown with error Fatal Error: Unable to connect to PulseAudio: OK. And this is the content of the terminal which is opened with Sound check pulseaudio:

Sound check for pulseaudio sound. (Option --pulseaudio)

You should hear some noise.
Error messages indicate that no pulseaudio connection has been set up.

***************************************************
$ pactl info
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

***************************************************
$ paplay -v /usr/share/games/xboard/sounds/cymbal.wav
Opening a playback stream with sample specification 's16le 1ch 11025Hz' and channel map 'mono'.
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

Could you try in Cygwin as well?

I had an issue to start it (see https://github.com/mviereck/x11docker/issues/155#issuecomment-493563805). After working around it, I get the same results as with MSYS2 and VcXsrv.

NOTE: pulseaudio is allowed in the firewall.

mviereck commented 5 years ago

Can you please try pavucontrol.exe from Cygwin? That is the one check I can do myself, and it works. x11docker --pulseaudio --exe pavucontrol.exe

Edit.

I think that unable to read any entries from file "(stdin)" might be familiar to you.

I've seen that before, but has been fixed a long time ago. I've checked both MSYS2 and Cygwin with --vcxsrv and --xwin, I cannot reproduce the issue. My Windows VM installation just had an update, too.

eine commented 5 years ago

Can you please try pavucontrol.exe from Cygwin? That is the one check I can do myself, and it works. x11docker --pulseaudio --exe pavucontrol.exe

My bad. pavucontrol was not installed in cygwin. I installed it now and ./x11docker --display 101 --pulseaudio --exe pavucontrol.exe works. But, as you suggested, the volume is at level 0.

When I try ./x11docker --display 101 --pulseaudio --clipboard --no-auth x11docker/check now, a Volume Control@42b289e5501a window is opened, and the following message is shown Establishing connection to PulseAudio. Please wait.... It never connects, but it does neither freeze nor crash.

I've seen that before, but has been fixed a long time ago. I've checked both MSYS2 and Cygwin with --vcxsrv and --xwin, I cannot reproduce the issue. My Windows VM installation just had an update, too.

It is strange because the cookie seems to be properly generated, and the environment variables inside the container have the expected content. Might xsetroot: command not found be related to this?

mviereck commented 5 years ago

When I try ./x11docker --display 101 --pulseaudio --clipboard --no-auth x11docker/check now, a Volume Control@42b289e5501a window is opened, and the following message is shown Establishing connection to PulseAudio. Please wait.... It never connects, but it does neither freeze nor crash.

That looks promising! Than there is probably some authentication issue left. It is either the firewall or a wrong pulseaudio module setup. The line of interest for pulseaudio authentication is https://github.com/mviereck/x11docker/blob/master/x11docker#L5382


  case $Winsubsystem in
    "") $Mksu "pactl load-module module-native-protocol-tcp  port=$Pulseaudioport auth-ip-acl=${Containerip:-"127.0.0.1"} 2>&1" >>$Messagelogfile ;;
    *)  env XDG_RUNTIME_DIR="" HOME="" cmd.exe /C "$Cygwinbinpath/pactl.exe load-module module-native-protocol-tcp  port=$Pulseaudioport auth-ip-acl=${Containerip:-$Hostip} 2>&1" 2>&1 >>$Messagelogfile ;;
  esac

Authentication for Pulseaudio access is ruled with module-native-protocol-tcp for defined IP addresses. In general the command seems to be ok because it works for pavucontrol.exe on host. Maybe $Containerip is wrong or empty?

You could encapsulate the quoted code with set -x and set +x to see the real command in the terminal output.

Edit:

Might xsetroot: command not found be related to this?

No. xsetroot just sets a solid grey background color for the X server. Otherwise it can be just black and hides the mouse cursor this way. The command is not important, just for convenience and a nicer look.

eine commented 5 years ago

You could encapsulate the quoted code with set -x and set +x to see the real command in the terminal output.

+ case $Winsubsystem in
+ env XDG_RUNTIME_DIR= HOME= cmd.exe /C 'F:/cygwin64/bin/pactl.exe load-module module-native-protocol-tcp  port=52401 auth-ip-acl=172.17.0.5 2>&1'
+ set +x
mviereck commented 5 years ago

That looks quite correct. pactl is called,the path is in F:/, and the IP looks well.

Can you somehow check if that is really the container ID and not the host IP? Maybe adding:

note "Hostip: $Hostip
Containerip: $Containerip"

However, it looks like a normal docker container IP. If the container IP is ok, I have no further idea. Alternatively x11docker could set up pulseaudio without authentication at all, but I would not like to do that.

eine commented 5 years ago

The IP is correct:

Hostip: 10.0.75.1
Containerip: 172.17.0.5

Alternatively x11docker could set up pulseaudio without authentication at all, but I would not like to do that.

I think it is ok to just add a note explaining that pulseaudio might not work.

mviereck commented 5 years ago

Re: Authorization issue

@1138-4EB Please let's discuss that in #160

mviereck commented 5 years ago

Re: pulseaudio

@1138-4EB Let's discuss the pulseaudio issue in #161

mviereck commented 5 years ago

Closing this ticket, it is too long and already contains different issues. Feel free to open a new ticket about x11docker/check if you have further thoughts.