Questions about XDG_RUNTIME_DIR and server-socket-dir

Questions about XDG_RUNTIME_DIR and server-socket-dir

[Phil Sainty]

The recent change to server-socket-dir to use the XDG_RUNTIME_DIR
environment variable is breaking some of my tooling, so I want to
understand the matter better.

The essence of my issue is that, via my wrapper script, a user can
run multiple independent Emacs instances, including running multiple
Emacs servers, and it's necessary that I'm not depending on
--daemon=NAME to differentiate the server sockets in this situation,
because the user should be able to specify any arbitrary options,
and should be able to have a non-server instance call (server-start)
to create a new non-conflicting server with the default server-name.

At present I automatically establish a distinct TMPDIR for each
instance, and until Emacs 27 this has worked well: server-socket-dir
was relative to TMPDIR, and so it didn't matter whether multiple
servers had a common server-name, as the sockets themselves were in
different directories.

With the new behaviour, the socket filenames are all in a common
directory, and so unless a distinct server-name is specified,
conflicts occur.

XDG_RUNTIME_DIR is completely new to me, so I'm uncertain how I should
fix this.

I can, of course, create a temporary XDG_RUNTIME_DIR the same way that
I create a temporary TMPDIR (the new dir is a sub-dir of the original
dir), which would deal with the conflicts; but as such a change is
reflected in process-environment inside Emacs, any processes that
Emacs creates will see the modified XDG_RUNTIME_DIR too, and maybe
that's not ok?  I'm relatively comfortable with this being the case
for TMPDIR, but I don't know about XDG_RUNTIME_DIR.  Does that get
used in ways that rely upon its path never changing?

If it's not safe to change it, then I think I need a way to specify
the server-socket-dir via some new environment variable?

NEWS says that:

> *** Emacs and emacsclient now default to $XDG_RUNTIME_DIR/emacs
> as the directory for client/server sockets, if Emacs is running
> under an X Window System desktop that sets the XDG_RUNTIME_DIR
> environment variable to indicate where session sockets should go.
> To get the old, less-secure behavior, you can set the
> EMACS_SOCKET_NAME environment variable to an appropriate value.

It appears to me that *only* emacsclient respects the EMACS_SOCKET_NAME
environment variable.  Emacs itself ignores it when establishing the
socket, as far as I can see.  (This is a current bug?)

I think EMACS_SOCKET_NAME is, in any case, not suited for my purposes,
as it represents a combination of server-socket-dir and server-name,
and the emacsclient option --socket-name overrides it such that
--socket-name=foo would be looking for foo in the default location,
even if EMACS_SOCKET_NAME specified a directory.

Can we perhaps introduce an EMACS_SOCKET_DIR environment variable
which is respected by both emacs and emacsclient?


-Phil

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Eli Zaretskii]

On February 3, 2019 7:21:37 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
> The recent change to server-socket-dir to use the XDG_RUNTIME_DIR
> environment variable is breaking some of my tooling, so I want to
> understand the matter better.
> 
> The essence of my issue is that, via my wrapper script, a user can
> run multiple independent Emacs instances, including running multiple
> Emacs servers, and it's necessary that I'm not depending on
> --daemon=NAME to differentiate the server sockets in this situation,
> because the user should be able to specify any arbitrary options,
> and should be able to have a non-server instance call (server-start)
> to create a new non-conflicting server with the default server-name.
> 
> At present I automatically establish a distinct TMPDIR for each
> instance, and until Emacs 27 this has worked well: server-socket-dir
> was relative to TMPDIR, and so it didn't matter whether multiple
> servers had a common server-name, as the sockets themselves were in
> different directories.
> 
> With the new behaviour, the socket filenames are all in a common
> directory, and so unless a distinct server-name is specified,
> conflicts occur.
> 
> XDG_RUNTIME_DIR is completely new to me, so I'm uncertain how I should
> fix this.
> 
> I can, of course, create a temporary XDG_RUNTIME_DIR the same way that
> I create a temporary TMPDIR (the new dir is a sub-dir of the original
> dir), which would deal with the conflicts; but as such a change is
> reflected in process-environment inside Emacs, any processes that
> Emacs creates will see the modified XDG_RUNTIME_DIR too, and maybe
> that's not ok?  I'm relatively comfortable with this being the case
> for TMPDIR, but I don't know about XDG_RUNTIME_DIR.  Does that get
> used in ways that rely upon its path never changing?
> 
> If it's not safe to change it, then I think I need a way to specify
> the server-socket-dir via some new environment variable?
> 
> NEWS says that:
> 
> > *** Emacs and emacsclient now default to $XDG_RUNTIME_DIR/emacs
> > as the directory for client/server sockets, if Emacs is running
> > under an X Window System desktop that sets the XDG_RUNTIME_DIR
> > environment variable to indicate where session sockets should go.
> > To get the old, less-secure behavior, you can set the
> > EMACS_SOCKET_NAME environment variable to an appropriate value.
> 
> It appears to me that *only* emacsclient respects the
> EMACS_SOCKET_NAME
> environment variable.  Emacs itself ignores it when establishing the
> socket, as far as I can see.  (This is a current bug?)
> 
> I think EMACS_SOCKET_NAME is, in any case, not suited for my purposes,
> as it represents a combination of server-socket-dir and server-name,
> and the emacsclient option --socket-name overrides it such that
> --socket-name=foo would be looking for foo in the default location,
> even if EMACS_SOCKET_NAME specified a directory.
> 
> Can we perhaps introduce an EMACS_SOCKET_DIR environment variable
> which is respected by both emacs and emacsclient?
> 
> 
> -Phil

The value of server-name can include leading directories, so I think you can already have what you want.  Right?

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Phil Sainty]

On 3/02/19 7:01 PM, Eli Zaretskii wrote:
> The value of server-name can include leading directories, so I think
> you can already have what you want.  Right?

I don't see any current way of specifying the server-name via the
environment when running emacs, though?

For hopeful clarity, my requirement includes the situation where a
user has an init file containing (server-start) (let's say that's all
that it contains), and they run plain 'emacs' via the wrapper twice,
and should end up with two separate emacs instances, each running its
own server using a distinct non-conflicting socket.

The wrapper doesn't know whether their init file will start a server;
but if a server is started then it must not conflict with other Emacs
servers (created with or without the wrapper).

And if the user instead ran 'emacs --daemon=foo' via the wrapper twice,
then again there should be two non-conflicting 'foo' sockets.

Making the wrapper control TMPDIR achieves all this for previous
versions.

(If they ran 'emacs --daemon=/path/to/foo' twice then it's fine for
that to conflict.  It's just the default server-socket-dir that I'm
wanting to have environmental influence over.)


-Phil

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Eli Zaretskii]

On February 3, 2019 11:18:28 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
> On 3/02/19 7:01 PM, Eli Zaretskii wrote:
> > The value of server-name can include leading directories, so I think
> > you can already have what you want.  Right?
> 
> I don't see any current way of specifying the server-name via the
> environment when running emacs, though?


The client already heeds to EMACS_SOCKET_NAME.  As for the server, since Emacs is invoked via a wrapper, I presume the wrapper could set server-name from the same environment variable, via --eval, no?

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Phil Sainty]

On 2019-02-04 00:21, Eli Zaretskii wrote:
> The client already heeds to EMACS_SOCKET_NAME.  As for the server,
> since Emacs is invoked via a wrapper, I presume the wrapper could set
> server-name from the same environment variable, via --eval, no?

No, --eval isn't processed until after the init file is processed,
so if the user called (server-start) in their init file then the socket
is already set.

My recollection is that I couldn't find any way of doing something
like that.  In the past I had used --daemon=NAME with a custom NAME
if the user explicitly told the wrapper to run a server; but once
it occurred to me that an init file with (server-start) remained a
problem I switched to setting TMPDIR.  At the time I spent a while
trying to figure out what my options were, and that was the only
method I could come up with which would work in general.

It sounds like a custom XDG_RUNTIME_DIR is the simplest way forward,
so I'll use that approach for now.

(I do still think a EMACS_SOCKET_DIR environment variable would be a
beneficial addition, as the current code doesn't facilitate this.)


-Phil

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Eli Zaretskii]

> Date: Mon, 04 Feb 2019 10:12:50 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: emacs-devel@gnu.org
> 
> On 2019-02-04 00:21, Eli Zaretskii wrote:
> > The client already heeds to EMACS_SOCKET_NAME.  As for the server,
> > since Emacs is invoked via a wrapper, I presume the wrapper could set
> > server-name from the same environment variable, via --eval, no?
> 
> No, --eval isn't processed until after the init file is processed,
> so if the user called (server-start) in their init file then the socket
> is already set.

You can always restart the server with another --eval, right?

> My recollection is that I couldn't find any way of doing something
> like that.

Only because yours is a very convoluted arrangement, not typical of
"normal" usage.  Defcustoms are supposed to be customized from init
files, not controlled by environment variables from outside of Emacs.

> (I do still think a EMACS_SOCKET_DIR environment variable would be a
> beneficial addition, as the current code doesn't facilitate this.)

We don't need a variable to set a directory when we already have one
for setting the file name, which could include leading directories.

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Stefan Monnier]

BTW, I noticed that while I typically use the emacsclient from my
"in-place" build of Emacs, I also sometimes use /usr/bin/emacsclient
from the Debian package.

Since those two don't use the same directory to look for the socket,
I end up just creating a symlink from the old /tmp/emacs<uid> location
to the new /run/user/<uid>/emacs directory.

I haven't bothered to teach server.el to do that for me (I do it by
hand when the need appears), but maybe we should.


        Stefan

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Phil Sainty]

On 2019-02-04 16:30, Eli Zaretskii wrote:
> You can always restart the server with another --eval, right?

I think that would be closing the stable door after the horse has
bolted, if the default socket had potentially been clobbered in
the interim :)


> Only because yours is a very convoluted arrangement, not typical
> of "normal" usage.

Oh absolutely.  (Although I believe others will find the script useful
as well once I've released it more generally, so it might become at
least slightly less abnormal.)


> Defcustoms are supposed to be customized from init
> files, not controlled by environment variables from outside of Emacs.

It's only the fact that separate instances can conflict with one
another's sockets which makes me want this, because that's rather an
awkward issue which (in my convoluted arrangement) isn't reliably
addressed by init files simply because I'm not imposing any particular
requirements on init files (and users might run 'emacs -q' in any
case).  Enforcing the separation of server instances really needs some
kind of external support.


>> (I do still think a EMACS_SOCKET_DIR environment variable would be a
>> beneficial addition, as the current code doesn't facilitate this.)
> 
> We don't need a variable to set a directory when we already have one
> for setting the file name, which could include leading directories.

I can only reiterate that this doesn't cover my particular use-case;
but that's ok, as it seems that setting XDG_RUNTIME_DIR will be a
workaround for that.  If I find that I need to revisit this question,
I'll provide more context.

Shall I raise a bug report for the fact that emacs ignores that existing
(EMACS_SOCKET_NAME) environment variable?


-Phil

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Paul Eggert]

Phil Sainty wrote:

> I don't know about XDG_RUNTIME_DIR.  Does that get
> used in ways that rely upon its path never changing?

XDG_RUNTIME_DIR is a per-user-login directory that is like TMPDIR except without 
some of the security problems of TMPDIR (e.g., an attacker can create a symlink 
in TMPDIR to some victim location). That is, XDG_RUNTIME_DIR is accessible only 
to you, whereas TMPDIR traditionally is world-accessible. Also, 
XDG_RUNTIME_DIR's lifetime is intended to be just while the user is logged in. 
For more, please see:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

I don't see the harm in changing it, if each new setting is intended to 
correspond to a different user login. That might be simpler than adding yet 
another environment variable.

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Phil Sainty]

On 3/02/19 7:10 PM, Paul Eggert wrote:
> XDG_RUNTIME_DIR is a per-user-login directory that is like TMPDIR except
> without some of the security problems of TMPDIR [...]
> 
> I don't see the harm in changing it, if each new setting is intended to
> correspond to a different user login. That might be simpler than adding
> yet another environment variable.

In my case a single user login could use multiple values -- each of the
Emacs instances (and inferior processes thereof) that the user ran
during that login session would be seeing a different XDG_RUNTIME_DIR.

If it's intended to be a replacement for TMPDIR though, perhaps changing
XDG_RUNTIME_DIR is no worse than changing TMPDIR.


-Phil

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Paul Eggert]

Phil Sainty wrote:
> If it's intended to be a replacement for TMPDIR though, perhaps changing
> XDG_RUNTIME_DIR is no worse than changing TMPDIR.

That sounds right. The replacement XDG_RUNTIME_DIR should follow the same 
security rules as the original, of course.

Re: Questions about XDG_RUNTIME_DIR and server-socket-dir

[Ulrich Mueller]

>>>>> On Sun, 03 Feb 2019, Paul Eggert wrote:

> XDG_RUNTIME_DIR is a per-user-login directory that is like TMPDIR
> except without some of the security problems of TMPDIR (e.g., an
> attacker can create a symlink in TMPDIR to some victim location). That
> is, XDG_RUNTIME_DIR is accessible only to you, whereas TMPDIR
> traditionally is world-accessible. Also, XDG_RUNTIME_DIR's lifetime is
> intended to be just while the user is logged in. For more, please see:

> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

That limited lifetime is also one of its problems, as I had already
pointed out in bug #33847. XDG_RUNTIME_DIR will disappear when the login
session ends, leading to an Emacs daemon process that has no socket and
can no longer be connected to. However, I suspect that some peoples'
workflow includes an Emacs daemon process that persists their login
session, which is no longer possible with the new location (at least not
in the default configuration).

> I don't see the harm in changing it, if each new setting is intended
> to correspond to a different user login. That might be simpler than
> adding yet another environment variable.

I had suggested (including a patch) in bug #33847 that the client should
fall back to TMPDIR if it doesn't find the socket in XDG_RUNTIME_DIR.
That way, the daemon could started from an environment without
XDG_RUNTIME_DIR (i.e., with the socket in TMPDIR, persisting login
sessions), and emacsclient would still find the socket, even if the
users started it from a GUI session.