Re: X11Forward and xauth problems

[Jon TURNEY <jon.turney@dronecode.org.uk>]

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