X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=NU+N38+2wakfmH6M
	gcO762e1spXT+ES436aVn+OCo/oqo6Esj90oWufw9Rhw/h8AHN30TsHliLEtcq7S
	5CNCjO8gMbOCBFAcwcMw0O039HmPH0AyTD+in8cU9LY+vtkGx6OFgeSKk7gnlKrZ
	cQI/rc9quOZVoYp6bKQxq9w/Cj0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=xtF//VcvdRPG3HmUVyMv8m
	UbHlY=; b=UYYmoeqggtLxN2yYFf9IjsTvj5JZNwcs8HWLULG9YOV+FtNNq1igGB
	vMYRDUWw4gcG3e0+1Hw0MP8MdLZhus51Z0iqkKOG22AEXVUz6xpyqR++OSyhzlxS
	7JtWGhFM6ao/yGfzpK7DNO4a7VoAASuWFWpQUfvhq5cpGzFEKOrUE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-HELO: out2-smtp.messagingengine.com
Message-ID: <55145A0D.4010406@dronecode.org.uk>
Date: Thu, 26 Mar 2015 19:12:13 +0000
From: Jon TURNEY <jon DOT turney AT dronecode DOT org DOT uk>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: Andrew DeFaria <Andrew AT DeFaria DOT com>
Subject: Re: X11Forward and xauth problems
References: <mepu7q$9dr$1 AT ger DOT gmane DOT org> <55108046 DOT 1070206 AT dronecode DOT org DOT uk> <meq0g3$hob$1 AT ger DOT gmane DOT org> <55115B29 DOT 8000904 AT dronecode DOT org DOT uk> <meurth$g26$1 AT ger DOT gmane DOT org>
In-Reply-To: <meurth$g26$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 25/03/2015 17:40, Andrew DeFaria wrote:
> Prediction: This problem probably will end up having something to do
> with the permissions and file system that ~/.Xauthority resides on,
> which is, I believe, a NetApp. This file system is the file system for
> the Linux Home directories (Windows "home" directories are somewhere
> else). In an attempt to have a transparently workable environment I set
> my Cygwin home directory to access the same directory my Linux servers
> use for the home directory - this NetApp. If you need more information
> about that then let me know and perhaps tell me how I can get that.

This seems very plausible.

If I am understanding you correctly, ~/.Xauthority is the same file on 
the NetApp at both ends.  I think perhaps that is somehow the cause of 
the problem.

The sequence of actions is something like:

- startx(|win) generates a random cookie and stores it in 
~/.serverauth.<pid> and uses that file as the server -auth option
- it also uses 'xauth add' to put that cookie into ~/.Xauthority for the 
display (e.g. :0)
- ssh reads that cookie out of ~/.Xauthority using 'xauth list' and 
sends it to the far end
- sshd tries to store that cookie using xauth for the proxy display (e.g 
:10)

Reading the source of xauth [1], it does try to lock the ~/.Xauthority 
file for up to 20 seconds before giving up, which perhaps corresponds to 
the delay you see?

However, the "unable to link authority file .Xauthority, use 
.Xauthority-n" message indicates that the working file .Xauthority-n 
cannot renamed as .Xauthority (xauth tries both to hard-link it as 
.Xauthority, and to rename it)

Of course, sshd doesn't understand it's helpful advice to use a 
different filename, so things don't work out so well. :)

Given that it works the first time, when there is no existing 
~/.Xauthority, perhaps the NetApp doesn't permit this file to be renamed 
over an existing file, for some reason?

You can tell startx to use a different file by using the XAUTHORITY env 
var, so setting that to something like ~/.Xauthority-$HOSTNAME might be 
a workaround. (Some googling on 'Xauthority hostname nfs' might be 
informative)

Or editing startx and changing enable_xauth to 0 might also be a workaround.

> As you can see with my current ~/.Xauthority file things don't work. But
> if I remove them, the ~/.Xauthority* files one is created at the next
> login and everything works fine. Log out and back in however and it
> breaks again.

>>>> If you want this to work, you will now (since X server 1.17) need to
>>>> start the server with the option '-listen tcp'.
>>>
>>> Restarted Xwin with -multimonitor and -listen tcp. Now I get:
>>
>> Sorry for any ambiguity, but you have misunderstood what I wrote.
>>
>> If you want explicitly setting DISPLAY and allowing access using xhost
>> to work, you must start the server with the option '-listen tcp'.
>
> Sorry I misunderstood. This works for me and is a work around. But I
> wish I could get that xauth thing working correctly.

Good.

[1] http://cgit.freedesktop.org/xorg/app/xauth

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple