From:	CSBVAX::CSBVAX::MRGATE::"SMTP::PREP.AI.MIT.EDU::INFO-GNU-EMACS-REQUEST"  9-NOV-1988 20:13
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: Socket created by emacsclient server


Received: from TUT.CIS.OHIO-STATE.EDU by prep.ai.mit.edu; Wed, 9 Nov 88 19:14:19 EST
Received: by tut.cis.ohio-state.edu (5.59/2.881028)
	id AA28798; Wed, 9 Nov 88 19:02:19 EST
Received: from USENET by tut.cis.ohio-state.edu with netnews
	for info-gnu-emacs@prep.ai.mit.edu (info-gnu-emacs@prep.ai.mit.edu)
	(contact usenet@tut.cis.ohio-state.edu if you have questions)
Date: 9 Nov 88 23:12:05 GMT
From: bucsb!jbw@bu-cs.bu.edu  (Joe Wells)
Organization: Boston Univ Comp. Sci.
Subject: Re: Socket created by emacsclient server
Message-Id: <2159@bucsb.UUCP>
References: <8811081608.AA17358@prep.ai.mit.edu>, <26736@ucbvax.BERKELEY.EDU>
Sender: info-gnu-emacs-request@prep.ai.mit.edu
To: info-gnu-emacs@prep.ai.mit.edu

In article <26736@ucbvax.BERKELEY.EDU> roland@wheaties.ai.mit.edu (Roland McGrath) writes:
>Unix-domain sockets are removed by unlink, so a rm command and probably
>the Emacs-Lisp delete-file function will remove them.

The bind call for AF_UNIX sockets has the side effect of leaving
behind an inode, even after all file descriptor references to the
socket have been closed.  Presumably the inode is created so that the
kernal namei function can be used to find the socket corresponding to
an address.

>) With the recent virus attacks in mind, it seems that leaving this
>) socket open could present a potential problem.
>
>You are completely wrong.  You are, of course, free to run around
>removing .emacsserver sockets all day if you're paranoid, but they are
>harmless.
>
>Unix-domain sockets, just like Internet sockets, need listeners in order
>to be used by any client.  If there is an existing socket with protection
>777 in your home directory, some server process may be able to use that
>as the binding for its Unix-domain socket, but all a client using this
>socket will have access to is whatever that server process gives it.
>So unless you run a server that opens a shell to clients using that
>socket, or root does, there is no security problem (if you happen to care
>about those, which most non-paranoid people don't).

This is correct, as long as you don't have a server process running
connected to an active GNU Emacs process.  If you have called
server-start from inside of emacs, and have not set the variable
inhibit-local-variables to a non-nil value, then you have given anyone
sufficiently clever complete access to your account.

When a client connects to the ~/.emacs_server socket, it can send a
message to the server process, which will be passed on to the emacs
process, which can result in find-file-noselect being called with
arbitrary arguments.  find-file-noselect calls normal-mode which calls
hack-local-variables which will execute arbitrary function calls in
the text of the target file unless inhibit-local-variables is set.

The server process does not do any checking on the identity of the
client process and neither does the emacs process.  (I just checked
the code in etc/server.c and lisp/server.el)  I don't know whether
changing the permissions on the socket inode will affect which
processes can connect to the socket.  Perhaps someone who has read the
relevant portion of the BSD code can comment.

Joe Wells
INTERNET: jbw%bucsf.bu.edu@bu-it.bu.edu
UUCP: ...!harvard!bu-cs!bucsf!jbw