Bug 446672 - gdm shouldn't disable tcp X connections by default
gdm shouldn't disable tcp X connections by default
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
: 449971 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-15 12:32 EDT by Ronald Kuetemeier
Modified: 2015-01-14 18:21 EST (History)
7 users (show)

See Also:
Fixed In Version: 2.22.0-8.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-01 01:27:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ronald Kuetemeier 2008-05-15 12:32:13 EDT
Documents do not mention on how to enable remote x, defaults to -nolisten tcp.
Docs @.
http://live.gnome.org/GDM/2.22/Configuration

Or is there a way to get 2.20 back, 2.22 is not ready for people in a Unix
environment.
Comment 1 Ronald Kuetemeier 2008-05-15 23:34:30 EDT
Looked through the maillist.
It's not possible. 

"That's correct we don't have a way to allow tcp connections to the x
server at the moment.  It is on our to-do list:
http://live.gnome.org/GDM/ToDo"

Thanks for putting a half working system in production.
Comment 2 David Wood 2008-05-21 07:42:24 EDT
Really keen to see this fixed too.
Comment 3 Ronald Kuetemeier 2008-05-21 09:31:14 EDT
David,
to get around it. Run or switch to run level 3, and then run x with startx.
GDM also prevents a lot of other Gnome applications to run, specially from the
CLI since DISPLAY is set to ip:0.
This is a typical Microsoft Windows thing. Who ever got rid of tcp never worked
or has seen a Unix shop. 

Comment 4 Darryl Bond 2008-05-24 00:33:47 EDT
This is a real pain.
I worked around it (for the moment) by using kdm instead. 
in /etc/sysconfig/desktop
DISPLAYMANAGER=KDE

You can still use gnome. 

If, like me you have heaps of users, kdm presents them as a vertical list so you
only see the first 10 or so. Not tested in a large environment either.

In /etc/kde/kdm/kdmrc fix the relevent settings.
UserList=false
ServerArgsLocal=-br -nolisten tcp
Comment 5 Mikko Huhtala 2008-06-24 06:24:12 EDT
Do I understand correctly that 

[security]
DisallowTCP=false

in /etc/gdm/custom.conf is ignored on purpose? At least it does not work for me
using gdm-2.22.0-5.fc9.i386. If so, why? Is this one of those
lets-remove-a-feature-for-the-hell-of-it GNOME things?
Comment 6 Ronald Kuetemeier 2008-06-24 10:09:32 EDT
No, No.
This is more lets get rid of as many features as we can.
gdmsetup, no tcp (which brakes also apps started from cli which rely on DISPLAY
set to ip) , no autologin, make the login screen look really amateur, just come
to mind.
Or who needs Unix/Linux features lets all be like Windows.
As you can see I'm not to happy about it. Or Fedora 9. Linus was right ... again. 
Comment 7 Ray Strode [halfline] 2008-06-25 09:37:17 EDT
So, I think we should just toggle this on by default.

I mean, 

1) the default firewall rules already block tcp access so it's not like there's
any added security in the default case
2) it's apparently causing real headaches for people
3) Turning it on by default won't slow down the typical case because we will
still communicate over a local socket by default.
Comment 8 Ray Strode [halfline] 2008-06-25 10:54:20 EDT
It was pointed out to me that a lot of users disable the system firewall at
install time, so 1 above doesn't hold true.

I'm going to add the old option back instead with it default to off.
Comment 9 Fedora Update System 2008-06-25 13:35:21 EDT
gdm-2.22.0-6.fc9 has been submitted as an update for Fedora 9
Comment 10 Darryl Bond 2008-06-25 17:12:26 EDT
I don't think that this is the problem here. the old version of GDM had an
option to enable TCP. The new one does not. There is no capability at all to
enable TCP.
DisallowTCP=false
does nothing. This means that you _cannot_ use gdm and expect DISPLAY=IP:0 to
work _at all_

I have no problem with it defaulting to off but I would like to be able to turn
it on.
Comment 11 Ray Strode [halfline] 2008-06-25 23:38:44 EDT
Darryl, can you try gdm-2.22.0-6.fc9 and report whether it addresses your issue?
 The point of the update is to add back the DisallowTCP option.
Comment 12 Fedora Update System 2008-06-26 04:32:28 EDT
gdm-2.22.0-6.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5719
Comment 13 Mikko Huhtala 2008-06-26 05:56:16 EDT
gdm-2.22.0-6.fc9 works for me.
Comment 14 Darryl Bond 2008-06-26 20:21:04 EDT
That fixes the -nolisten tcp. 

I still cannot connect to IP:0.0 without playing with xauth. 

I tried it as root. Log in to get a desktop as root.

# xwininfo -root - works
# xwininfo -root -display localhost:0 - works
# xwininfo -root -display IP:0 - doesn't work (/var/log/Xorg.0.log shows the reject)
# xhost +
# xwininfo -root -display IP:0 - now works

I assume that there is some strangeness with the cookie.

Darryl

Comment 15 Ray Strode [halfline] 2008-06-27 11:02:27 EDT
We don't allow clients to connect unauthenticated.  They have to know the
generated password (authentication cookie) for the server to allow them access.

Comment 16 Darryl Bond 2008-06-28 00:42:27 EDT
That's true. But even root while logged into an xwindows session cannot open a
window on that Xserver if the tcp connection is used, ie -display IPAddress:0.0
but -display localhost:0.0 and -display :0.0 works. 

This is a new behaviour. Authenticated X sessions used to be able to open
windows using the IPAddress:0
Comment 17 Darryl Bond 2008-06-28 00:59:32 EDT
My IP address is 192.168.12.100. I am logged onto the machine with an X session
that is working fine.

$ xhost
access control enabled, only authorized clients can connect
SI:localuser:me
$ xterm -display 192.168.12.100:0
No protocol specified
xterm Xt error: Can't open display: 192.168.12.100:0
$ xhost 192.168.12.100
192.168.12.100 being added to access control list
$ xhost
access control enabled, only authorized clients can connect
INET:192.168.12.100
SI:localuser:me
$ xterm -display 192.168.12.100:0.0

I suspect gdm is not setting the xhost or cookie correctly.
Comment 18 Darryl Bond 2008-06-29 00:49:29 EDT
Aghhh, I found this
http://www.nabble.com/Why-do-GDM-2.22.0-set-xauth-file-owner-as-login-user-td17371800.html.
The behaviour has changed quite a lot.
I wonder what is the correct way to use the new regime.
Comment 19 Fedora Update System 2008-07-01 01:27:21 EDT
gdm-2.22.0-8.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Darryl Bond 2008-07-02 06:26:33 EDT
It still won't allow using tcp sockets due to xauth.
Here is what my machine has using kdm
$ xauth list
192.168.12.100:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
172.31.100.254:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
192.168.122.1:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
[fe80::21d:7dff:fee6:9b48]:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
[fe80::248:54ff:fe3f:5bed]:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
[fe80::c8ec:18ff:fe37:eb42]:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
[fe80::984e:e0ff:fe64:4dbd]:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc
gold/unix:0  MIT-MAGIC-COOKIE-1  e69ee76b144631b1f0d2495c249447fc

Using gdm, only the last line (ie unix sockets). 


Comment 21 Ray Strode [halfline] 2008-07-02 09:49:20 EDT
Hi Darryl,

I've cloned this to bug 453775.  Let's fix the auth entries up on that report
(since this one is already closed)
Comment 22 Tom Hughes 2008-07-03 03:35:57 EDT
*** Bug 449971 has been marked as a duplicate of this bug. ***

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