0

By default, older versions of Xvnc listened for connections from x-windows clients on ports 6000+. This functionality could be disabled by the "-nolisten TCP" command line option. In turn, the GNOME desktop manager controlled this option via the "DisallowTCP" setting in /etc/gdm/custom.conf.

More recently, "-nolisten TCP" is the default behavior and listening on port 6000+ has to be explicitly enabled with "-listen TCP". The GNOME desktop manager is supposed to be smart enough to know that "DisallowTCP=false" equates to "-listen TCP", but in RHEL 8.4, this does not appear to work.

Has anyone found a way to enable listening on ports 6000+ on RHEL 8.4?

Andrew Vickers
  • 2,504
  • 2
  • 10
  • 16
  • There's a long [chapter](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/customizing-gnome-desktop-features_using-the-desktop-environment-in-rhel-8) in the redhat docs on remote access using VNC, but it uses different port numbers. – meuh Jul 03 '21 at 08:36
  • Yes. The VNC ports (5900+) are used by the VNC client to connect to the VNC server. That is a different component of the display technology, and that is all working as expected. The issue here is the TCP ports used by Xwindows-based applications to connect to the Xwindows server component of the VNC server. This is the piece that does not appear to be working as documented in RHEL 8.4. – Andrew Vickers Jul 03 '21 at 13:22
  • 1
    Here is my REAL problem: I have a script that runs from cron on another machine. That script opens an SSH connection to my machine, and then launches an application that requires an X-windows DISPLAY. The source machine does not have an X-windows display, so I cannot use 'ssh -X'. The destination machine is running Xvnc on display ":1". If I export "DISPLAY=:1", "DISPLAY=unix/:1", or "DISPLAY=localhost:1", then run the application, it always fails with "unable to open display". Perhaps there is a way to force the application to use the unix domain socket instead of a TCP socket? – Andrew Vickers Jul 03 '21 at 15:01

1 Answers1

1

So it turns out that the "right" solution to my problem is to let the application/xwin libraries figure out for itself the best mechanism to use for connecting to the local xwindows server. The missing piece was that the xwindows server has to allow connections from processes that it does not control (i.e. those started by the GNOME desktop).

I solved the problem as follows:

  1. In the user's ~/.vnc/xstartup file, add the command 'xhost +'
  2. Restart the vncserver service to pick up the change.
  3. When the remote process has connected via SSH, set the display environment variable without specifying the host: 'export DISPLAY=':1', before running the xwin application.

Problem solved without using TCP.

I still think this is a Red Hat/GNOME bug, but at least I can work around it to solve my real problem.

Andrew Vickers
  • 2,504
  • 2
  • 10
  • 16
  • `xhost +` is unsafe. – KJ7LNW Mar 13 '23 at 23:46
  • Thanks. Do you have a better solution? – Andrew Vickers Mar 15 '23 at 01:58
  • `xhost +127.0.0.1` is better if you trust the host because `xhost +` allows connections from anywhere. – KJ7LNW Mar 15 '23 at 22:01
  • See also: https://superuser.com/questions/310197/how-do-i-fix-a-cannot-open-display-error-when-opening-an-x-program-after-sshi – KJ7LNW Mar 15 '23 at 22:01
  • You might also look into how the `.Xauthority` file works. I don't know the details but `ssh -X` plumbs it so there is a way to do it locally, too. – KJ7LNW Mar 15 '23 at 22:11
  • Thanks. These are interesting leads, but they do not directly address the underlying issue. xhost +127.0.0.1 doesn't work because the connection uses a Unix-domain socket, not an IP address. The good news is that Unix-domain sockets are inherently local, so the security risk is significantly reduced. – Andrew Vickers Mar 24 '23 at 13:28
  • `xhost +local` or `xhost +si:localuser:` might do what you want. From `man xhost`: _"The local family specifies all the local connections at once. However, the server interpreted address "si:localuser:username" can be used to specify a single local user. (See the Xsecurity(7) manual page for more details.)"_ – KJ7LNW Mar 25 '23 at 00:45