Bug 187637 - Applications that depend on usermode are refused connection by Xvnc or Xnest
Summary: Applications that depend on usermode are refused connection by Xvnc or Xnest
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: 5
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-02 03:04 UTC by Shane Stixrud
Modified: 2008-03-11 16:48 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-03-11 16:48:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Shane Stixrud 2006-04-02 03:04:04 UTC
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:

Comment 1 Erik Rudd 2006-04-23 00:29:19 UTC
This behavior is 100% repeatable in core 5.

Comment 2 Miloslav Trmač 2007-03-10 21:47:29 UTC
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?

Comment 3 Tomas Mraz 2008-01-30 15:57:50 UTC
No response from reporter.

Comment 4 Miloslav Trmač 2008-01-31 03:38:01 UTC
This bug was NEEDINFO: sandmann.

Soren, can you take a look at comment #2, please?

Comment 5 petrosyan 2008-03-11 16:48:19 UTC
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.