Bug 80358 - s-c--network - change hostname, X failure
Summary: s-c--network - change hostname, X failure
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
: 86136 (view as bug list)
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2002-12-24 22:30 UTC by Warren Togami
Modified: 2007-11-30 22:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-07 11:56:57 UTC
Type: ---

Attachments (Terms of Use)

Description Warren Togami 2002-12-24 22:30:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218

Description of problem:
Read the entire story here

If you change your system hostname in the "DNS" tab and click Activate, it
causes new X windows to connect to your X server for the remainder of your
session.  In a terminal you see things like this error message:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Perhaps it should display a message something like, "You must restart X for this
change to take effect." and/or delay changing hostname until X is restarted. 

Version-Release number of selected component (if applicable):
Phoebe redhat-config-network-1.1.86-1

How reproducible:

Steps to Reproduce:
1. Run redhat-config-network
2. Change hostname in "DNS" tab
3. Click activate
4. Attempt to launch any new window

Comment 1 Mike A. Harris 2003-01-09 13:00:38 UTC
Since the hostname is used in authentication, the hostname of a machine
must NOT change while the X server is running.  This is not a bug, but is
a very intentional security feature.

I'm not sure how best the user interface should handle this type of thing,
but I just wanted to indicate that it is not an X bug.  I'm adding Havoc
to the CC list for his HID comments as well.

Comment 2 Havoc Pennington 2003-01-09 14:45:55 UTC
I do think it is an X bug, though I realize it's a design bug rather than 
an "oops" bug.

There are other ways to do authentication, at least on localhost.
X does support multiple auth mechanisms and we could add more.

For local connections, using SO_PEERCRED with getsockopt() is appealing.

Comment 3 Harald Hoyer 2003-02-05 12:10:17 UTC
well, this bug could byte you in any case.. dhcp or shells hostname command
so, assigning to X

Comment 4 Mike A. Harris 2003-02-07 12:14:09 UTC
hp) Seemingly unnecessary.  The code is already there, or at least as
far as I can tell looking at it.  It is purposefully disabled when
authentication is enabled in the server for security purposes, or at
least as far as I understand the code.

I'm not sure what is required to enable this, but there are likely
security ramifications of doing so.  Someone who understands X
authentication deeply, and all of the security ramifications will
need to comment on this.  Also, I wont make any changes to authentication
mechanisms unless they're blessed by upstream and included directly
in upstream sources.

Deferring for future review.

Comment 5 Mike A. Harris 2003-02-07 12:17:31 UTC
 * called when authorization is not enabled to add the
 * local host to the access list
EnableLocalHost (void)
    if (!UsingXdmcp)
        LocalHostEnabled = TRUE;
        AddLocalHosts ();
 * called when authorization is enabled to keep us secure
DisableLocalHost (void)
    HOST *self;
    LocalHostEnabled = FALSE;
    for (self = selfhosts; self; self = self->next)
        (void) RemoveHost ((ClientPtr)NULL, self->family, self->len,

Comment 6 Mike A. Harris 2003-02-07 12:39:23 UTC
After doing a bit more snooping around, I've determined that this isn't an
X problem to solve, but should be solved in the config tool that changes
the interface underneath X.

man xhost

       You can't specify a display on the command line because -display  is  a
       valid  command  line  argument  (indicating that you want to remove the
       machine named ``display'' from the access list).
       The X server stores network addresses, not host  names.   This  is  not
       really a bug.  If somehow you change a host's network address while the
       server is still running, xhost must be used  to  add  the  new  address
       and/or remove the old address.

Comment 7 Harald Hoyer 2003-02-07 12:43:17 UTC
err, if I change the IP address and have the X tool run remotly, the TCP
connection gets destroyed anyway...
If I have DISPLAY=:0, then X should unix sockets and not care about... 
xauth should then maybe not store the hostname...

Comment 8 Harald Hoyer 2003-02-07 12:44:25 UTC
or the ip adress... cause the unix socket does not have any...

Comment 9 Harald Hoyer 2003-02-07 12:46:41 UTC
this will byte you also, if you get another dhcp address...
maybe if unix sockets are used then the inode no. should be used.

Comment 10 Mike A. Harris 2003-05-16 06:43:43 UTC
inodes are host dependant.  If you used inodes, homedirs couldn't be shared
between machines over NFS.

Comment 11 Havoc Pennington 2004-02-27 20:37:50 UTC
This is really easy, right now X writes a file with hostname-cookie
pairs. Just write integer-cookie pairs instead, have the X server give
the integer to the client as a challenge, and the client looks up the
cookie by number intead of by hostname.

Comment 12 Warren Togami 2004-07-27 00:35:14 UTC
Any chance we can have this fixed before FC3?

Comment 13 Havoc Pennington 2004-07-27 02:13:19 UTC
Someone could fix it, yes, but I don't know of anyone planning to
spend the couple weeks that are probably needed (the actual patch may
only take a couple days, but needs discussion on the x.org lists, and
probably would have to go through a couple of iterations)

D-BUS has a working cookie system that would do the job... or just use
Kerberos auth... or UNIX socket credentials... anything but

Comment 16 Chris Kuivenhoven 2004-09-04 21:45:20 UTC

The new URL for the problem description that Warren posted is:


-Chris Kuivenhoven

Comment 19 Sitsofe Wheeler 2004-11-14 15:54:10 UTC
I was going to open another bug to file this against FC3 but as this
is against devel I guess it is unecessary.

Mandrakelinux have a program called s2u
) that works around this problem. Perhaps this could be included /
adapted for Fedora...

Comment 22 Mike A. Harris 2005-02-01 09:09:26 UTC
Setting status to DEFERRED for review for FC5/RHEL5 devel cycle.

Comment 23 Mike A. Harris 2005-04-20 15:07:55 UTC
*** Bug 86136 has been marked as a duplicate of this bug. ***

Comment 24 Kyrre Ness Sjøbæk 2005-05-02 20:59:24 UTC
I have a computer here running devel (xorg 6.8.2-29), that has had the hostname
"mona" since install.

When i su - to root, and then tries to run a system-config (such as
system-config-securitylevel), it does get the

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

If i then run "xhost +", it works. But i should not have to do that - it worked
in fc3. -> regression?

Methinks SUSE has the same behaviour.

Comment 25 Mike A. Harris 2005-05-02 23:10:44 UTC
(In reply to comment #24)
> I have a computer here running devel (xorg 6.8.2-29), that has had the hostname
> "mona" since install.
> When i su - to root, and then tries to run a system-config (such as
> system-config-securitylevel), it does get the
> Xlib: connection to ":0.0" refused by server
> Xlib: No protocol specified
> If i then run "xhost +", it works. But i should not have to do that - it worked
> in fc3. -> regression?
> Methinks SUSE has the same behaviour.

Your problem is actually not a bug, but a configuration/usage error on
your part, which is completely unrelated to the problem described in this
bug report.  You might find the fedora-list@redhat.com mailing list
helpful in determining the proper configuration/invocation however.

Comment 26 Mike A. Harris 2005-09-28 22:51:15 UTC
The crux of this problem is not an X bug, but an unfortunate
design limitation.  Fixing this problem requires feature work
to be done on future X releases, and should be treated as a
feature enhancement done in upstream X.Org.

Please file a feature enhancement request in the X.Org bugzilla
located at http://bugs.freedesktop.org in the "xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker.

Setting status to "NEEDINFO_REPORTER", and awaiting upstream
feature request URL.

Comment 28 Mike A. Harris 2006-03-07 11:56:57 UTC
Realistically this feature needs to be requested upstream and then implemented
upstream in a new X.Org release before it'll be included in Fedora Core.

Closing WONTFIX, however if someone files (or finds) an upstream bug report
for it, and pastes the URL here, we'll continue to track it in RH bugzilla also.

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