Trouble with xauth and ssh -Y since 1.7 upgrade

["Jeffrey C. Jacobs" <darklord at timehorse dot com>]

This morning, I wanted to get the wdiff package so I loaded up my
setup only to find it was time to upgrade my setup. ÂUh, oh, looks
like we're on 1.7 now so major upgrade just for this 1 package.
>sigh< ÂWell, as I was sleepless at 1a45 and had a few hours before
work, and didn't want to manually select 'skip' for the hundred or so
packages that were being marked for upgrade so that I can have fun
with 1.7, I read the change log notes, decided I didn't care about
/etc/fstab and all the other things seemed minor so what the hay...

So I do this, and, well, apart from the update updating qt3 then
telling me that it and many other things are not updated on rerun then
updating those then telling me 3 gnome packages and qt3 need updating
so I update those so the same list of packages from before now need
updating and back and forth like the dependancy tree is broken. ÂWell,
I say this but I doubt this be the issue but it probably explains the
result of cygcheck reporting some incomplete, as can be seen below.

But I provide that not to bore you but as back story to what I think
is going on here. ÂSee, at first I could no longer run X. ÂEventually
I found in the FAQ question 3.4:
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file
and, well, I have FAT on that machine (ostensibly for TiVo hacking)
and so tweaking my shortcut to add "-- -nolock" to the "startxwin.exe"
command, X came up like a charm.

Then, I went to another machine and used my second favourite ssh
option: "-Y" ("-L" is the first, in case you're wondering). ÂAnd what
do you think I saw? ÂOur old friend:

/usr/bin/xauth: Âcreating new authority file /home/<uid>/.Xauthority
/usr/bin/xauth: Âunable to link authority file
/home/<uid>/.Xauthority, use /home/<uid>/.Xauthority-n

The heck! ÂOkay, so having read the FAQ and read and read and read so
many articles hither and thither thanks to Google, I have come up with
the theory that CygWin 1.7 breaks X11 Forwarding on a CygWin Host with
a FAT32 file system because CYGWIN 1.7 changes how locks are performed
and thus when sshd runs xauth it is unable to open ~/.Xauthority,
creates ~/.Xauthority-n instead and does NOT set DISPLAY and does NOT
allocate a display in /tmp as it used to. ÂThat is to say, ls -lauF
/tmp/.X11-unix produces:

drwxr-xr-x 1 <uid> None 0 2010-03-06 00:00 ./
drwxr-xr-x 1 <uid> None 0 2010-01-10 00:00 ../
srw-r--r-- 1 <uid> None 0 2010-03-10 00:00 X0=

IIRC, there used to be an entry in /tmp/.X11-unix for each connected
display, so I think the xauth isn't the only issue going on here.
Also, I modified /etc/sshd_config to set XAuthLocation to
"/usr/bin/xauth -v -i -b" and restarted the sshd service to force the
server to break any locks on ~/.Xauthority if any exists before
authenticating. ÂAlthough this made the error go away, it didn't a)
turn on verbose mode, since sshd adds '-q' to the parameter list of
xauth, which disables '-v' and b) still doesn't create ~/.Xauthority.

So, although I don't really want to go through the rigmarole of
running convert.exe -- partly because I'm pretty sure there isn't
enough free space on the drive to run it anyway -- I would consider it
*if* I can be sure it's the only way I'll ever be able to X11 Forward
again. ÂSo, can anyone confirm that xauth is permanently broken under
FAT32? ÂOr am I missing something? ÂThanks!

Here's my cygcheck for my Win XP box...

<cygcheck removed because I could not submit the original message; it
was reported as s p a m!>

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