Bug 43425 - xauth is unable to handle "FamilyWild" resulting in X11 forwarding problems with SSH
Summary: xauth is unable to handle "FamilyWild" resulting in X11 forwarding problems w...
Status: CLOSED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xauth (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard: 2011BRB_Reviewed
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-12-01 08:11 UTC by Dr. Tilmann Bubeck
Modified: 2014-06-26 05:52 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to improve xauth to handle FamilyWild (3.53 KB, patch)
2011-12-01 08:45 UTC, Dr. Tilmann Bubeck
no flags Details | Splinter Review
improve xauth to handle FamilyWild (2.76 KB, patch)
2012-08-08 13:16 UTC, stefan.volkel.ext
no flags Details | Splinter Review

Description Dr. Tilmann Bubeck 2011-12-01 08:11:51 UTC
There is a long and detailed discussion of this problem in Red Hat Bugzilla under https://bugzilla.redhat.com/show_bug.cgi?id=505545

Short problem description:
==========================

If using GDM with XDMCP, then ssh is not able to start X11 clients on the remote side. You get a "No xauth data; using fake authentication data for X11 forwarding." from SSH.

Detailed problem description:
=============================

The problem is, that xauth is unable to deal with the Family "FamilyWild" which is used by GDM in XDMCP to store the MIT-MAGIC-COOKIE-1 for the user.

This results in SSH not being able to get the MIT-MAGIC-COOKIE-1 of the user, because "xauth list $DISPLAY" does not match the DISPLAY (because it does not understand FamilyWild).

This results in SSH not being able to ForwardX11 and therefore no X11 client could be started on the remote side.

Solution:
=========

I developed a patch to improve xauth to handle FamilyWild. I will submit this patch using GIT in a moment.
Comment 1 Dr. Tilmann Bubeck 2011-12-01 08:45:03 UTC
Created attachment 54022 [details] [review]
Patch to improve xauth to handle FamilyWild
Comment 2 Jeremy Huddleston Sequoia 2012-01-02 12:44:07 UTC
Please send your patch to the xorg-devel list for review
Comment 3 stefan.volkel.ext 2012-08-07 14:02:10 UTC
Since we are hitting the same issue, what is the status of this bug?
Comment 4 Dr. Tilmann Bubeck 2012-08-07 14:50:50 UTC
I sent it to the list and there was a remark about a memory leak. This is probably true, but I do not think, that this is too important, because xauth runs only for a fraction of a second, and does not collect memory like a daemon.

However, I offer to look into the memory leak and update the patch if there is a chance of the patch beeing accepted.

An alternative could be for the xauth authors to implement FamilyWild on their own.
Comment 5 Alan Coopersmith 2012-08-07 15:16:01 UTC
(In reply to comment #4)
> An alternative could be for the xauth authors to implement FamilyWild on their
> own.

The xauth authors haven't worked on xauth in over a decade.   X.Org developers
maintain it in their spare time, but waiting for us to decide to work on a
problem caused by other programs putting unexpected data in the auth file may
not be a quick process.
Comment 6 stefan.volkel.ext 2012-08-08 13:16:20 UTC
Created attachment 65284 [details] [review]
improve xauth to handle FamilyWild

An updated version of the orignal patch:

  - free host an rest on failed parse_displayname(), avoids memleak
  - reformat memcmp in match_authwild_dpy(), easier to read

This is against xauth-1.0.7
Comment 7 Dr. Tilmann Bubeck 2012-08-09 05:31:24 UTC
Comment on attachment 65284 [details] [review]
improve xauth to handle FamilyWild

Review of attachment 65284 [details] [review]:
-----------------------------------------------------------------

Looks good. :-)
Comment 8 Dr. Tilmann Bubeck 2013-10-11 19:25:14 UTC
Fixed in xauth-1.0.8 released today.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.