emacsclient and XAUTHORITY variable

emacsclient and XAUTHORITY variable

[Ulrich Mueller]

The following came up in https://bugs.gentoo.org/555346 where a user
complained that the XAUTHORITY variable in emacsclient's environment
wouldn't be honoured. I closed that Gentoo bug report, arguing that
"[...] the emacs daemon needs to read X authentication information
from the ~/.Xauthority file. Storing this information in a different
place and pointing XAUTHORITY to it won't work, because the daemon
cannot see this XAUTHORITY variable in its environment."

Thinking about it again, I wonder if this wasn't a premature
conclusion. Creating a frame with emacsclient and calling

   (getenv "XAUTHORITY" (selected-frame))

in the newly created frame shows that XAUTHORITY (or in fact, any
variable from emacsclient's environment) will be passed on to the
frame's "environment" parameter. So Emacs has all information which is
necessary, and I wonder if this couldn't be passed to the Xau library
before opening the X display for the new frame?

There is also bug http://debbugs.gnu.org/1467 which seems to be
related.

Ulrich

Re: emacsclient and XAUTHORITY variable

[Stefan Monnier]

> frame's "environment" parameter. So Emacs has all information which is
> necessary, and I wonder if this couldn't be passed to the Xau library
> before opening the X display for the new frame?
> There is also bug http://debbugs.gnu.org/1467 which seems to be
> related.

I'm pretty sure that in theory it can be handled, indeed.
I don't know how much work it would entail in practice.

I must say that I find it a pain in the rear (as a plain user) that gdm3
started to set XAUTHORITY rather than to put the auth data where god
intended it to be (i.e. ~/.Xauthority).  "emacsclient" is not the only
victim, so I'm not highly motivated to fix the problem on Emacs's side.


        Stefan

Re: emacsclient and XAUTHORITY variable

[Ulrich Mueller]

>>>>> On Thu, 06 Aug 2015, Stefan Monnier wrote:

>> frame's "environment" parameter. So Emacs has all information which
>> is necessary, and I wonder if this couldn't be passed to the Xau
>> library before opening the X display for the new frame?

> I'm pretty sure that in theory it can be handled, indeed.
> I don't know how much work it would entail in practice.

I've started to look into it, and it seems that Xau wasn't designed
with that problem in mind. The relevant function is XauFileName, which
checks the XAUTHORITY environment variable, or otherwise defaults to
~/.Xauthority. Other than that, there is no way of telling Xau about
the file's location. Neither can it handle multiple auth files.

So about the only possibility would be to temporarily add the
XAUTHORITY variable to Emacs' environment (that is, the real
environment, not 'process-environment') before opening the X display.
Not sure if this could be implemented without being too fragile.

> I must say that I find it a pain in the rear (as a plain user) that
> gdm3 started to set XAUTHORITY rather than to put the auth data
> where god intended it to be (i.e. ~/.Xauthority). "emacsclient" is
> not the only victim, so I'm not highly motivated to fix the problem
> on Emacs's side.

I agree, everyone using ~/.Xauthority would be the better solution.

Ulrich