Using Emacs server and emacsclient on other machines as other users

问题

I know that after I call (start-server) inside an existing Emacs session I can then use emacsclient -c (on the same computer) to create new frames that connect into that server, so that each new frame created by emacsclient has access to the same set of shared state (e.g. buffers).

Most of the documentation I've found focuses on the "give me fast access to my local Emacs" use case, and so there are two things that I haven't seen any details of yet:

Can emacsclient -c access Emacs servers started by other users, or is it hard-wired to detect only sessions started by my own user?
Does Emacs server (directly or indirectly) support remote connections? That is, is there some way to set up Emacs (possibly involving SSH) that allows calls to emacsclient -c on remote machines to have access to the local state of my Emacs server?

(In case you haven't already guessed, what I'd ultimately like to do is combine the two techniques above to provide rudimentary collaborative editing support.)

This is a real-world problem, so here's what I'm working with:

The necessary functionality should be built into Emacs already (23.3.1, 64-bit). I can stretch to Emacs extensions from the standard Ubuntu repositories, but I'd prefer not to. (Which I believe rules out Rudel, sadly.)
No new users or user spoofing. Solutions should work with the existing set of user accounts, and users must not pretend to be other users (e.g. via su or ssh).

If it makes any difference, the machines are on a private LAN, have OpenSSH clients and servers installed (and running), and all users can connect to (their own account on) all machines, but they have no shared filesystem.

So, does anybody know whether Emacs server can

grant access to other users, or
provide remote access?

EDIT

As commented in rwb's answer, it's clear that the new windows being opened locally by running emacsclient -c are actually being created by the remote Emacs server process. That is, emacsclient is simply triggering the relevant behaviour in the server. This causes some issues with incorrect display settings, since the server does not normally have access to the local desktop (see below). However, I can now connect in to a remote Emacs session if I use the following sequence of commands:

In one terminal, where 1.22.333.44 is the IP address of remotehost:

ssh -t -X remotehost \
  "emacs -nw --eval
   '(progn (setq server-host \"1.22.333.44\" server-use-tcp t) (server-start))'"

Then in another (on the same machine):

scp remotehost:.emacs.d/server/server /tmp/server-file
DISPLAY=localhost:10 emacsclient -c -f /tmp/server-file

The emacsclient command causes the remote Emacs server (which it finds details of in /tmp/server-file) to open up a graphical Emacs window (on the local display) that shares state with the Emacs session on the remote host.

Since the remote Emacs server was started via ssh -X, SSH provides it with access to my local display via a "fake" :10 display. The DISPLAY=:10 passed to it (via emacsclient) thus causes a window to be opened on my local desktop.

Although the approach above does tick the "Run Emacs server on remote machine, connect to it using emacsclient locally" box, it's very limited. In fact, it's not much different to running the server and clients all locally as a single user: the only difference is that the server is now remote, so has access to different system resources.

Unfortunately, launching via ssh -X is the only way I've been able to successfully open a window on a different machine's X server:

Specifying a basic DISPLAY=remote:0 gets nowhere (since Ubuntu X servers are started with the -nolisten tcp option).
Connecting via SSH and then using DISPLAY=:0 also fails, but this time only due to lack of suitable authentication credentials. (I believe that's the case, anyway: the error message cryptically says No protocol specified / Can't open display.)

I think that finding a way around the second problem would probably get me a good deal closer to a solution.

Having read the posts at http://comments.gmane.org/gmane.emacs.devel/103350 (starting at the '25 Oct 14:50' post, about half way down) I'm starting to wonder if this might be one of the rare things that Emacs cannot do (i.e. is impossible ;-) ).

However, if anyone does have a way to provide access to remote X displays without the permissions error above, I'm still open to persuasion....

TL;DR

As pointed out by rwb's answer, my questions above about whether Emacs can grant remote access have got things backwards. There's no real problem with Emacs granting access to other users (server-use-tcp and a suitable server-file take care of this): rather the problem is how to allow a process on one machine to open new X windows on other users' X displays (specifically, the Emacs running (start-server) needs to open windows for users who ask it to via emacsclient -c). That answer's beyond the scope of this question.

Alternative solution

As a workaround, we use the following:

machine0: tmux -S /tmp/shared-tmux-socket new-session
machine1..machineN: ssh -t machine0 tmux -S /tmp/shared-tmux-socket attach

with suitable file permissions on /tmp/shared-tmux-socket.

Then we run a text-mode Emacs in the shared terminal. :-) This does raise some user-spoofing questions, but at least the host can see everything that the guests are doing.

回答1:

I think what you're asking for is impossible by definition, because if you give a remote user unrestricted access to your Emacs, this is just as much "user spoofing" as letting that remote user access a shell via ssh. To spell it out, from a security point of view this is probably a bad idea.

Also, the results of letting two users access one Emacs aren't as good as you might hope. It isn't designed with simultaneous access in mind. It's years since I tried it, so things might have moved on a bit, but when I did it was quirky to say the least.

Still, I'll try to answer your question.

It sounds like you're thinking about this back-to-front, because, counter-intuitively, in network terms, the X11 display is the server, and the X11 application is the client. This is surprising because typically the display is local to the user and the application is running on some remote server.

You can instruct a running emacs to connect to a remote display and open a new window with M-x make-frame-on-display. For this to work, the owner of that display will need to grant you access to it.

We will assume host-l is the computer that is running Emacs, and that you want to make it accessible to a user of display 0 on host-r. Be aware that you've said you don't want to use SSH forwarding, so following this method will cause all traffic will go across the network unencrypted.

First, make sure that display host-r:0 is accepting TCP connections. You don't mention your operating system, but this is probably the default on Unix and probably isn't on Linux (for security reasons). If, for example, the following mentions -nolisten tcp then you'll need to change this configuration.

host-r$ ps -ef | grep X

Next, get the user of host-r to run the following, and send you the output. Be sure to warn them that this will allow you to take complete control of their current desktop session, should you choose.

host-r$ xauth list $DISPLAY
host-r/unix:0  MIT-MAGIC-COOKIE-1  01234567890abcdef0123456789abcd

This is, effectively, the "password" for the display. On host-l, put it where Emacs will be able to find it with:

host-l$ xauth add host-r:0 MIT-MAGIC-COOKIE-1  01234567890abcdef0123456789abcd

Now enter M-x make-frame-on-display host-r:0 and an Emacs window should pop up on the remote display.

回答2:

This should provide a starting point for what you want.

From the info node (emacs) emacsclient Options

`--server-file=SERVER-FILE'
     Specify a "server file" for connecting to an Emacs server via TCP.

     An Emacs server usually uses an operating system feature called a
     "local socket" to listen for connections.  Some operating systems,
     such as Microsoft Windows, do not support local sockets; in that
     case, Emacs uses TCP instead.  When you start the Emacs server,
     Emacs creates a server file containing some TCP information that
     `emacsclient' needs for making the connection.  By default, the
     server file is in `~/.emacs.d/server/'.  On Microsoft Windows, if
     `emacsclient' does not find the server file there, it looks in the
     `.emacs.d/server/' subdirectory of the directory pointed to by the
     `APPDATA' environment variable.  You can tell `emacsclient' to use
     a specific server file with the `-f' or `--server-file' option, or
     by setting the `EMACS_SERVER_FILE' environment variable.

     Even if local sockets are available, you can tell Emacs to use TCP
     by setting the variable `server-use-tcp' to `t'.  One advantage of
     TCP is that the server can accept connections from remote machines.
     For this to work, you must (i) set the variable `server-host' to
     the hostname or IP address of the machine on which the Emacs server
     runs, and (ii) provide `emacsclient' with the server file.  (One
     convenient way to do the latter is to put the server file on a
     networked file system such as NFS.)

You also may want to look at variables server-auth-dir, server-auth-key and server-port

回答3:

Aaron Gallagher implemented a solution: http://blog.habnab.it/blog/2013/06/25/emacsclient-and-tramp/

It works (AFAIU) like:

emacs server is started with tcp
He opens a connection to a remote system with tramp-sh, opening a forward port ("back channel")
tramp-sh is advised to copy an extended auth cookie file to the remote system
On the remote system he calls a special emacsclient.sh shell script that emulates emacsclient but prefixes the file names with the corresponding tramp prefix that is found in the extended auth cookie

I've added a comment to his blog post proposing this idea to be discussed and enhanced on emacs-devel.