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.

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.

well, this bug could byte you in any case.. dhcp or shells hostname command
so, assigning to X

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.

/*
 * called when authorization is not enabled to add the
 * local host to the access list
 */
 
void
EnableLocalHost (void)
{
    if (!UsingXdmcp)
    {
        LocalHostEnabled = TRUE;
        AddLocalHosts ();
    }
}
 
/*
 * called when authorization is enabled to keep us secure
 */
void
DisableLocalHost (void)
{
    HOST *self;
 
    LocalHostEnabled = FALSE;
    for (self = selfhosts; self; self = self->next)
        (void) RemoveHost ((ClientPtr)NULL, self->family, self->len,
(pointer)self->addr);
}

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


[SNIP]
BUGS
       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.

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...

or the ip adress... cause the unix socket does not have any...
reassigning

this will byte you also, if you get another dhcp address...
maybe if unix sockets are used then the inode no. should be used.

inodes are host dependant.  If you used inodes, homedirs couldn't be shared
between machines over NFS.

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.

Any chance we can have this fixed before FC3?

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
MIT-MAGIC-COOKIE

FYI,

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

http://listman.redhat.com/archives/phoebe-list/2002-December/msg00041.html

-Chris Kuivenhoven

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
(http://rpmfind.net/linux/RPM/mandrake/10.1/i586/media/main/s2u-0.2-2mdk.i586.html
) that works around this problem. Perhaps this could be included /
adapted for Fedora...

Setting status to DEFERRED for review for FC5/RHEL5 devel cycle.

*** Bug 86136 has been marked as a duplicate of this bug. ***

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.

(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 mailing list
helpful in determining the proper configuration/invocation however.

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.

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.