Red Hat Bugzilla – Bug 187637
Applications that depend on usermode are refused connection by Xvnc or Xnest
Last modified: 2008-03-11 12:48:19 EDT
Description of problem: When running applications like system-config-users, system-config-services etc.. from an Xvnc or Xnest session the applications are refreshed from the local Xserver. Adding localhost to /etc/Xn.hosts works around this problem. As far as I can tell this occurs for any application that has the capability to escalate its privileges (i.e. depends on usermode) however this problem occurs even when the Xnest or Xvnc user is root. This problem does not exist exist in RHEL4 or RHEL3 but does in Core4 and Core5. Perhaps usermode is exporting to localhost:n instead of using UNIX sockets?? Version-Release number of selected component (if applicable): 1.85-2.2 How reproducible: Connect using Xnest -query hostname :1 run system-config-users from an xterm Steps to Reproduce: 1. Xvnc or Xnest into a core 5 host 2. open xterm / gnome-terminal 3. run system-config-users Actual results: system-config-users fails to start and reports the Xserver refused its connection Expected results: system-config-users starts up and is displayed on the Xvnc or Xnest X server. Additional info:
This behavior is 100% repeatable in core 5.
Thanks for your report. This is not related to consolehelper; running (su -) and attempting to use X in the root session fails in the same way. The session running in Xnest uses DISPLAY=amilo:1.0 (amilo is my hostname), and the Xauthority database contains the following three entries: amilo/unix:1 MIT-MAGIC-COOKIE-1 ... 127.0.0.1:1 MIT-MAGIC-COOKIE-1 ... 0.0.0.0:1 MIT-MAGIC-COOKIE-1 ... After (su -) or using consolehelper, pam_xauth creates a new Xauthority database for root, which contains only a single entry: 127.0.0.1:1 MIT-MAGIC-COOKIE-1 ... This seems to be correct, but it doesn't work: _X11TransConnectDisplay() in libX11 correctly connects to tcp/127.0.0.1:1, but it calls _X11TransConvertAddress (), which explicitly changes the address to FamilyLocal "amilo" (the comments refer to a "BSD hack localhost address 127.0.0.1"). Then it searches for an Xauthority record for amilo/unix:1, which is not present. Soren, is the "BSD hack" intentional behavior that should be supported by pam_xauth, or something obsolete that should be removed?
No response from reporter.
This bug was NEEDINFO: sandmann@redhat.com. Soren, can you take a look at comment #2, please?
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there have not been any updates to the report since thirty (30) days or more since we requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.