I just been hit by this bug. For now, I will use the workaround described in the Debian bug report (ie move credential to the standard Xautority and redefine XAUTHORITY to the standard place in .xsession). But I'm interested by the rational for this move in gdm3.

  Regards,
    Vincent

I'm also hit by the bug. I do sometimes need to run things remotely by simply setting DISPLAY. It used to work simply because it would use the standard .Xauthority place, which has been working nicely for decades, even with NFS mounts and whatnot. Why changing it for a place that the user can not even find (since /var/run/gdm3 is o-r)?

It caused a lot of issues, but I don't remember them all off hand since we made this change like 4 years ago (and some distros were doing it years before that).

My memory is pretty spotty here, but, I believe that one problem was that the file would tend to get out of date, having old hostnames in it. I also think it was identified as a source of robustness problems on network connection hiccups.  And there were issues with multiple machines using the same file at the same time.

having old hostnames in it is not really a problem, $HOME is already full of old cruft usually :) 

I don't see what issues network connection hiccups can bring to a $HOME/.Xauthority rather than /var/lib/gdm3. If $HOME is on NFS and NFS does not work, the user won't be able to use much of its session anyway. At best the distribution should put xauthority on /tmp, but not *hide* it in some place that the user can not even browse.

xauth uses file locking to fix multiple machines using the same file at the same time. And actually it's part of the whole purpose of using a .Xauthority file and not simply uid credentials over the local socket: being able to log on on several machines, and easily display a program on another simply by setting DISPLAY.

I'm still looking for a convincing rational for this change. Comment 3 does not have facts that convince me. And I fully agree with Samuel's comments. And I confirm that this behavior is really annoying when someone want to use the X session from a shell where XAUTHORITY is not set (from an SSH connection for example).

Distros normally have something like

xhost +si:localuser:`id -un`

in their xinit scripts, so you shouldn't need XAUTHORITY for the "ssh in and run a program on an existing server" situation.

But generally, to join an existing session you need more than XAUTHORITY.  You need one or more of DISPLAY, DBUS_SESSION_BUS_ADDRESS, XDG_SESSION_COOKIE, SESSION_MANAGER, etc etc. So if you've got to set DISPLAY and potentially these other things, why is XAUTHORITY a big deal?

You could also use a script like this one:

http://people.gnome.org/~halfline/join-session-with

and then just do 

join-session-with firefox

or whatever

Well, I'd say it's just gnomish crazyness. All you should need is the DISPLAY. Everything else can be (and are in standard protocols) stored as root window properties.

My use case is a 'ssh myserver' from my laptop to run mplayer on my server in order to see (and control mplayer from my laptop) some films on a video-projector.
  Until recently, I only needed to setup DISPLAY for that to work. Now, I would also need XAUTHORITY without a way to find it from a script (the directory in which gdm3 store it is not browsable by the user).
  So I need to modify a script when the gdm session starts. Instead of storing the value of XAUTHORITY in a file and having to setup it latterly, I just setup the workaround described in the Debian bug report and use plain ~/.Xauthority file again. It works perfectly and I see no reason why gdm3 tries to modify this legacy setup.
  Of course, I do not run (never tried) core gnome applications remotely. And indeed, I'm really disappointed to learn here that more than 5 environment variables seams to be required for that to work ! But, for most graphical applications, only modifying DISPLAY is the only thing needed.

(In reply to comment #8)
>   Until recently, I only needed to setup DISPLAY for that to work. Now, I would
> also need XAUTHORITY without a way to find it from a script (the directory in
> which gdm3 store it is not browsable by the user).
I'm not sure why things changed recently.  Like I said, we made this change ~4 years ago.

If you throw a file with

xhost +si:localuser:`id -un`

into /etc/X11/xinit/xinitrc.d (or whatever the exact location is on your distro)
you should be able to get rid of any other hacks.  A lot distros do this by default.  Then it's just setting DISPLAY like before for your specific use-case.

I guess GDM could do this on its own.

I noted it recently because I tried to switch from gdm to gdm3 recently. For now, I did the switch only on one of my computer.

The following fix has been pushed:
273d92c data: allow user to connect to his own displays automatically

Created attachment 199386 [details] [review]
data: allow user to connect to his own displays automatically

Many distros do:

xhost +si:localuser:`id -un`

in there local start up scripts.  This allows users connected
via ssh (or a tty) to just set DISPLAY and gain access to any
X servers that are running that they "own" without having to
mess around with XAUTHORITY.

This commit puts the equivalent change upstream.

Err, so instead of reverting a change whose reason is unknown, we have to add a hack somewhere else?

...

I don't know why you're calling the above a hack. Doing it seems to be a very reasonable and rational thing to do, completely independent of where the XAUTHORITY file is.

In case someone still wonders in the Cc list: we added this line to the common X11 scripts in Debian as well.