Bug 505545

looks like the hostname is getting written out with garbage, not sure why off hand.  Will need to investigate.

I had a look at gdm code and in daemon/gdm-display-access-file.c in the _get_auth_info_for_display subroutine (circa line 440) you have the code
        if (is_local) {
                char localhost[HOST_NAME_MAX + 1] = "";
                *family = FamilyLocal;
                if (gethostname (localhost, HOST_NAME_MAX) == 0) {
                        *address = g_strdup (localhost);
                } else {
                        *address = g_strdup ("localhost");
                }
        } else {
                *family = FamilyWild;
                gdm_display_get_remote_hostname (display, address, NULL);
        }
the entry seems to be consistent with the wildcard format, but it seems ssh -Y doesn't like it. However there is probably no reason to use the wildcard format anyway.

The patch below might be a possible approach to fix the problem from the gdm end. It works for me in some circumstances though won't for IPV6 or if there is a 0 in an IPV4 address (such as 127.0.0.1 which is the circumstance where it doesn't work for me).

--- gdm-2.26.1/daemon/gdm-display-access-file.c.orig	2009-03-26 19:15:09.0000
00000 +0000
+++ gdm-2.26.1/daemon/gdm-display-access-file.c	2009-08-21 11:35:01.000000000 +0
100
@@ -37,6 +37,10 @@
 #include <glib/gi18n.h>
 
 #include <X11/Xauth.h>
+#include <X11/X.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
 
 #include "gdm-display-access-file.h"
 #include "gdm-common.h"
@@ -446,8 +447,12 @@
                         *address = g_strdup ("localhost");
                 }
         } else {
-                *family = FamilyWild;
-                gdm_display_get_remote_hostname (display, address, NULL);
+		in_addr_t inp;
+		gdm_display_get_remote_hostname (display, address, NULL);
+		inp=inet_addr(*address);
+		g_debug ("_get_auth_info_for_display: IP is %d\n", inp);
+		*address = g_strndup(&inp, 4);
+                *family = FamilyInternet;
         }
         *address_length = strlen (*address);

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This is still an issue in Fedora 12 and 13.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This is still a problem in Fedora 14.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This is still an issue in Fedora 16.

I also came across that bug and before finding this bugzilla entry, I did also find out GDM to be the cause and also the above line, which is still there for GDM 3.2.1

After further investigation I found out, that the problem is IMHO not GDM but xauth.

The following happens:

1. GDM receives XDMCP request and creates a MIT-MAGIC-COOKIE-1 with FamilyWild.
2. This is stored in the users XAUTHORITY file.
3. If you use "xauth list" you will see the above entry. However, xauth is not
   able to deal with FamilyWild so it lists the entry as a unknown type.
   This is marked by starting the line with "#" and showing everything in hex.
   Here is an example:

   #ffff#31302e312e312e323030#:0  MIT-MAGIC-COOKIE-1 7f2ae3c1....9d943101

   This is problem #1.

4. If you use ssh to log into another computer, it will execute this before
   connecting: "xauth list $DISPLAY". In my case "DISPLAY=10.1.1.200:0".
   Because xauth does not know FamilyWild it will not match the above entry
   and will therefore print nothing. This will lead to the error message of ssh:
   "Warning: No xauth data; using fake authentication data for X11 forwarding."
   and X11 forwarding will not work.

   This problem #2 and related to problem #1.

There are 3 solutions to this problem:

A. Change from GDM to KDM which uses FamilyInternet instead of FamilyWild.

B. Patch GDM to use FamilyInternet instead of FamilyWild. This is known to
   xauth and will work. This is suggested above.

C. Improve xauth so that it will be able to deal with FamilyWild.

IMHO solution C is the best, because it will improve the situation in general instead of working around a problem in xauth.

I developed a patch based upon the current GIT of xauth. This patch improves xauth to handle FamilyWild. This patch is also submitted upstreams. I verified everything and the patch solves the problem without patching GDM.

Feel free to include this patch into Fedora if upstream is slow or unwilling to include.

Created attachment 539277 [details]
Patch to improve xauth to handle FamilyWild.

I can confirm that this patch (comment 18, Till Bubeck) works on RHEL6.3.
Without this patch xauth and an Xvnc server with XDMCP started from xinetd do not play nice together when using pam_xauth.so, with this patch everything works like a charm.

Thanks, Till. I just noticed this bug go by, moving to xorg-x11-xauth. I'll commit Michael's patch upstream in GDM so we get the best of both worlds.

Hmm actually that patch will need a bit of work, let me file upstream for now so I don't forget about it.

You don't need both patches. Why?

The main problem is, that xauth is unable to deal with the (specified) "FamilyWild" and xauth is used by SSH to transfer x11 authorization to the remote host.

Michael's patch from comment #3 changes GDM to use FamilyInternet instead of FamilyWild.

My patch fixes xauth to be able to deal with FamilyWild.

I would prefer fixing xauth instead of working around that missing functionality from xauth. So I suggest applying my patch against xauth and drop the patch from Michael, if my patch got applied.

To be clear, I'm saying:

1) It makes a ton of sense to fix xauth upstream and use it in fedora
2) In upstream GDM it makes sense to work with unfixed xauth too for wider compatibility.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

xauth-1.0.8 has been released upstreams (not yet packaged for Fedora), which fixes this bug.

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

Hi All,

Thanks for are your patience on this, and for making sure a fix was done upstream.

An update to 1.0.9 is on its way to updates-testing for F-19+.

Regards,

Hans

xorg-x11-xauth-1.0.9-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xorg-x11-xauth-1.0.9-1.fc20

xorg-x11-xauth-1.0.9-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-xauth-1.0.9-1.fc19

Package xorg-x11-xauth-1.0.9-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-xauth-1.0.9-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8077/xorg-x11-xauth-1.0.9-1.fc20
then log in and leave karma (feedback).

xorg-x11-xauth-1.0.9-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

xorg-x11-xauth-1.0.9-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.