Bug 187637 - Applications that depend on usermode are refused connection by Xvnc or Xnest
Applications that depend on usermode are refused connection by Xvnc or Xnest
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
David Lawrence
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-04-01 22:04 EST by Shane Stixrud
Modified: 2008-03-11 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-11 12:48:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Shane Stixrud 2006-04-01 22:04:04 EST
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):

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:
Comment 1 Erik Rudd 2006-04-22 20:29:19 EDT
This behavior is 100% repeatable in core 5.
Comment 2 Miloslav Trmač 2007-03-10 16:47:29 EST
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:
After (su -) or using consolehelper, pam_xauth creates a new Xauthority database
for root, which contains only a single entry: MIT-MAGIC-COOKIE-1 ...

This seems to be correct, but it doesn't work: _X11TransConnectDisplay() in
libX11 correctly connects to tcp/, but it calls
_X11TransConvertAddress (), which explicitly changes the address to FamilyLocal
"amilo" (the comments refer to a "BSD hack localhost address").  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?
Comment 3 Tomas Mraz 2008-01-30 10:57:50 EST
No response from reporter.
Comment 4 Miloslav Trmač 2008-01-30 22:38:01 EST
This bug was NEEDINFO: sandmann@redhat.com.

Soren, can you take a look at comment #2, please?
Comment 5 petrosyan 2008-03-11 12:48:19 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.