Bug 212926 - X11 forwarding broken for system-config-securitylevel
X11 forwarding broken for system-config-securitylevel
Product: Fedora
Classification: Fedora
Component: usermode (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-10-30 00:25 EST by Gabriel Schulhof
Modified: 2008-02-28 13:20 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-28 13:20:24 EST
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 Gabriel Schulhof 2006-10-30 00:25:09 EST
Description of problem:
user@host$ ssh root@remote_host
root@remote_host's password:
Last login: some time ago
[root@remote_host]# system-config-securitylevel &
[1] 31415
X11 connection rejected because of wrong authentication.
The application 'system-config-securitylevel.py' lost its connection to the
display localhost:10.0;
most likely the X server was shut down or you killed/destroyed
the application.
[root@remote_host]# xclock

In other words, system-config-securitylevel gives that error, whereas a simple X
app works as it should. In fact, several other system-config-... scripts produce
the same error. I suspect it has something to do with the userhelper (or
similar) wrapper.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. See above

Actual results:
See above error message

Expected results:
I should be able to run system-config-* by logging onto a system as root with
ssh X11 forwarding.

Additional info:
Comment 1 Gabriel Schulhof 2006-10-30 00:28:44 EST
P.S. & FWIW: SElinux is permissive on both computers - both are FC6.
Comment 2 Tomas Mraz 2006-10-31 08:39:35 EST
I cannot reproduce this on fully updated FC6. Reassigning to usermode where the
problem most probably is.
Comment 3 Miloslav Trmač 2007-03-10 17:21:36 EST
This might be a duplicate of #187637, please do the following to gather more

* log in to the remote host
* verify xclock works and s-c-securitylevel doesn't
* Run the following command and report its output:
  (echo DISPLAY=$DISPLAY; echo XAUTHORITY=$XAUTHORITY; echo hostname=$(uname -n);
   xauth -n list)
* While still logged on the remote host, run (su -) and check whether xclock
Comment 4 Miloslav Trmač 2008-02-28 13:20:24 EST
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.