thakur%cfa201@HARVARD.HARVARD.EDU (Manavendra K. Thakur) (11/09/88)
By loading and running the emacsclient server, you create a socket in
your home directory which is used for the interaction between emacs
and the calling process.
Unfortunately, if you exit emacs, this socket, which in my case has
777 permission, still sits around. There's nothing to delete it.
Is there anyone who can shed some light on how to delete this socket
automatically (is there an equivalent of the .logout file for emacs)?
It would be best to only create the socket as it was needed (i.e.
only when emacs was called by the client), and then delete it as the
when the client exits, but this may not be possible.
With the recent virus attacks in mind, it seems that leaving this
socket open could present a potential problem. Much as I dislike the
notion of clamping down on security, I have to admit that I didn't
like running around all day trying to eliminate the effects of the
virus (we did get hit). It seems to me that we can still preserve an
open computing environment in the Richard Stallman tradition but still
take minimal precautions (like deleting unused sockets lying around)
to prevent such attacks in the future.
Thoughts, comments, suggestions, anyone?
Manavendra K. Thakur
thakur@cfa200.harvard.edu
thakur%cfa@harvard.harvard.edumcgrath@tully.Berkeley.EDU.berkeley.edu (Roland McGrath) (11/09/88)
Unix-domain sockets are removed by unlink, so a rm command and probably the Emacs-Lisp delete-file function will remove them. ) 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). Roland McGrath roland@wheaties.ai.mit.edu, mit-eddie!wheaties.ai.mit.edu!roland
frank@morgan.com (Frank Wortner) (11/09/88)
>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. That is still not an excuse for a program to leave an unused socket lying around. If a sort program failed to remove temporary files after the program finished using them, most people would judge that the program had a bug. Any utility should take care to remove and/or release resouces it no longer needs. >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 Yet another thing root *shouldn't* do! What's the point of having a "super user" if (s)he has to remember not to: 1) have "." in the current search path; 2) run emacs servers ; 3) etc., ad nauseum ... :-) >about those, which most non-paranoid people don't). I don't think the label "paranoid" applies here, but if you want to use it, then I'm afraid that most computer installations are "paranoid" to one extent or another. Dismissing concern about the security and safety of data (which often represents much hard work) as "paranoia" just does not wash. Whether or not this particular problem proves to be a true risk (and that has not bee proven or disproven), it is a concern of an individual. That person deserves an answer, not an implied diagnosis of a psychological problem. Frank Now that I'm climbing off the soapbox, I hope no one in the audience brought any rotten vegetables.
jbw@bucsb.UUCP (Joe Wells) (11/10/88)
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