After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681170 - xauth data isn't in format ssh -Y likes
xauth data isn't in format ssh -Y likes
Status: RESOLVED OBSOLETE
Product: gdm
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-03 22:20 UTC by Ray Strode [halfline]
Modified: 2015-11-06 19:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2012-08-03 22:20:59 UTC
This bug "fell through the cracks" downstream here:

https://bugzilla.redhat.com/show_bug.cgi?id=505545

Michael Young 2009-06-12 07:35:51 EDT

If I make a connection to a server GDM with XDMCP enabled (eg. via Xnest -query server :1 ) and use this session to ssh -Y to another server, I get the warning
Warning: No xauth data; using fake authentication data for X11 forwarding.
when connecting, and attempts to start an X application (eg. xclock) fail with the error
Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: localhost:10.0
Back on the GDM session if I run xauth I get a line like
#ffff#3132392e3233342e322e313134#:1  MIT-MAGIC-COOKIE-1 33c9c88bbbf68a7290301845b5f9554c
and it seems ssh -Y doesn't understand that format (ssh -X doesn't have a problem). If I use xauth to add a line like
localhost:1 MIT-MAGIC-COOKIE-1 33c9c88bbbf68a7290301845b5f9554c
then ssh -Y starts working again.

[reply] [-]
Private
Comment 1 Ray Strode [halfline] 2009-08-04 09:40:40 EDT

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

[reply] [-]
Private
Comment 2 Michael Young 2009-08-04 10:44:16 EDT

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.

[reply] [-]
Private
Comment 3 Michael Young 2009-08-22 17:41:41 EDT

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);