Using Emacs and emacsclient on other machines as other users

I know that after calling (start-server) inside an existing Emacs session, I can use emacsclient -c (on the same computer) to create new frames that connect to this server, so that every new frame created by emacsclient has access to one and the same set of general conditions (e.g., buffers).

Most of the documentation I found focuses on “give me quick access to my local Emacs,” and so there are two things that I haven't seen about:

  • Can emacsclient -c access Emacs servers started by other users, or is it difficult to connect only sessions started by my own user?

  • Does the Emacs server support (directly or indirectly) remote connections? That is, is there a way to configure Emacs (possibly using SSH) that allows emacsclient -c calls on remote computers to access the local state of my Emacs server?

(In case you haven’t guessed yet, what I would ultimately want to do is combine the two above methods to provide rudimentary support for collaboration.)




This is a real problem, so here I work:

  • The required functionality should be built into Emacs already (23.3.1, 64-bit). I can stretch Emacs extensions from standard Ubuntu repositories, but I would prefer not to. (Which, I think, confuses Rudel,).
  • No new users or user spoofing. Solutions should work with the existing set of user accounts, and users should not pretend to be other users (for example, via su or ssh ).

If it matters, the machines are on a private LAN, the OpenSSH clients and servers are installed and running, and all users can connect to their computers (their own account), but they don’t have a common file system.




So, does anyone know if the Emacs server can

  • share with other users or
  • provide remote access?

EDIT

As indicated in rwb's answer, it is clear that new windows that open locally by running emacsclient -c are actually created by the remote Emacs server process. That is, emacsclient simply invokes the corresponding behavior on the server. This causes some problems with incorrect display settings, since the server usually does not have access to the local desktop (see below). However, I can now connect to a remote Emacs session if I use the following sequence of commands:

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

 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 forces the remote Emacs server (which it finds details in /tmp/server-file ) to open the Emacs graphical window (on the local display), which shares state with the Emacs session on the remote host.

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




Although the above approach makes the mark "Run Emacs server on a remote computer, connect to it using emacsclient locally", it is very limited. In fact, it is not much different from the fact that the server and clients work locally as one user: the only difference is that the server is now deleted, therefore it has access to various system resources.

Unfortunately, running through ssh -X is the only way I was able to successfully open a window on another X server computer:

  • Setting the base DISPLAY=remote:0 no good (since Ubuntu X servers start with the -nolisten tcp option).

  • Connecting via SSH and then using DISPLAY=:0 also fails, but this time only due to the lack of suitable credentials. (I believe 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 will probably bring me closer to a solution.




After reading the posts at http://comments.gmane.org/gmane.emacs.devel/103350 (starting at October 25, 2:50 p.m., about halfway down) m, starting to wonder if this might be one of the rare things that Emacs cannot do (i.e. impossible ;-)).

However, if anyone has a way to provide access to remote X-displays without the permission error above, I am still open to convince ....

TL; DR

As indicated in rwb's answer, my questions above about whether Emacs can provide remote access got things back. There is no real problem with providing Emacs to other users ( server-use-tcp and a suitable server-file ): rather, the problem is how to allow a process on one machine to open new windows X for other users "X displays (in particular, to start Emacs (start-server) you need to open windows for users who request it through emacsclient -c ). This answer is 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 appropriate file permissions on /tmp/shared-tmux-socket .

Then we run Emacs text mode in the shared terminal. :-) This raises some issues related to spoofing, but at least the host can see everything the guests are doing.

+46
emacs collaboration remote-access tmux emacsclient
Sep 22 '12 at 18:48
source share
4 answers

I think that what you are asking for is not possible by definition, because if you give the remote user unlimited access to your Emacs, it is also a “user spoofing” that allows the remote user to access the shell through ssh. From a security point of view, this is probably a bad idea.

In addition, the results allowing two users to access the same Emacs are not as good as you might expect. It is not intended for simultaneous access. Many years have passed since I tried, so everything could have changed a little, but when I did it, it was bizarre, to say the least.

However, I will try to answer your question.

It sounds like you are thinking about it, but intuitively, in network terms, X11 is the server, and the X11 application is the client. This is surprising, because usually the display is local to the user, and the application runs on some kind of remote server.

You can instruct running emacs to connect to the remote display and open a new window using Mx make-frame-on-display . For this to work, the owner of this screen must give you access to it.

Suppose host-l is the computer running Emacs, and that you want to make it available to the user mapping 0 to host-r . Keep in mind that you said you do not want to use SSH forwarding, so as a result of this method, all traffic will go through a network that is not encrypted.

First, make sure the host-r:0 display accepts a TCP connection. You do not mention your operating system, but this is probably the default on Unix and probably not on Linux (for security reasons). If, for example, the following mentions are -nolisten tcp , then you will need to change this configuration.

 host-r$ ps -ef | grep X 

Next, ask the user host-r to run the following and send you the result. Remember to warn them that this will allow you full control of the current desktop session, if you choose.

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

This is, in fact, the "password" to display. On host-l put it where Emacs can find it with:

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

Now enter Mx make-frame-on-display host-r: 0 , and the Emacs window will appear on the remote display.

+9
May 01 '13 at 20:00
source share
— -

This should be the starting point for what you want.

From emacscient information

 `--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 can also look at server-auth-dir , server-auth-key and server-port variables

+9
Sep 23
source share

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

It works (AFAIU), for example:

  • Emacs server starts with tcp
  • It opens a connection to the remote system using tramp-sh, opening the front port ("reverse channel")
  • tramp-sh is recommended to copy the auth extended cookie to the remote system.
  • On the remote system, it calls the special shell emacsclient.sh script, which emulates emacsclient, but the file name prefixes with the corresponding tramp prefix, which is in the extended auth cookie

I added a comment to his blog post, suggesting this idea to discuss and improve on emacs-devel.

+6
Sep 19 '13 at 16:47
source share

If you do this to allow people to edit files remotely, you can watch the "vagrant mode"

http://emacswiki.org/emacs/TrampMode

+3
Sep 23
source share



All Articles