From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Theodore Ts'o Newsgroups: gmane.emacs.devel Subject: Re: expressions Date: Tue, 7 Jan 2003 06:53:26 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20030107115325.GA475@think.thunk.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041967704 30417 80.91.224.249 (7 Jan 2003 19:28:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2003 19:28:24 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18VzMh-0007n5-00 for ; Tue, 07 Jan 2003 20:26:19 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18VzRO-0002NI-00 for ; Tue, 07 Jan 2003 20:31:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18VzF0-0004fD-00 for emacs-devel@quimby.gnus.org; Tue, 07 Jan 2003 14:18:22 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18VvVB-00060x-00 for emacs-devel@gnu.org; Tue, 07 Jan 2003 10:18:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18VvUf-0005Sw-00 for emacs-devel@gnu.org; Tue, 07 Jan 2003 10:18:48 -0500 Original-Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18VvU8-0004lb-00; Tue, 07 Jan 2003 10:17:44 -0500 Original-Received: from [194.196.100.59] (helo=think.thunk.org) by thunker.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 18VvTf-0000tM-00; Tue, 07 Jan 2003 10:17:15 -0500 Original-Received: from tytso by think.thunk.org with local (Exim 3.36 #1 (Debian)) id 18VvT5-0000hZ-00; Tue, 07 Jan 2003 10:16:39 -0500 Original-To: Bob Halley Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Original-cc: rms@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10532 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10532 On Sun, Jan 05, 2003 at 11:55:49AM -0800, Bob Halley wrote: > No, it is not safe. On Solaris, at least as recent as Solaris 8, the > file permissions on UNIX domain sockets are totally ignored. This may > be true on other platforms as well, though many platforms "do the > right thing" and check file permissions. Wow. I didn't realize Solaris was that broken/stupid. Although granted adding the ability to server.el to evaluate arbitrary LISP expression becomes a security disaster, even without that, users who have enable-local-variables set to t and who run server.el are in trouble --- since an attacker can ask emacs to open an arbitrary file created by the attacker, and the local variables in the file can contain arbitrary lisp expressions. > The standard way of dealing with this portably is to create a > directory for the socket filename to live in, and control access via > permissions on the directory. Yes, although this causes the backwards compatibility problems mentioned in other mail messages. One solution would be to allow the location to be configurable via an emacs-server variable to be one of the following possibilities, with emacsclient searching all of these locations: /tmp/esrv-hostname (for backwards compatibility with old emacsclient binaries) /tmp/esrv-/hostname (for homedirs using filesystems that don't support sockets) ~/.eserv/ (to avoid tmp cleaners) (BTW, Note that one way of dealing with the temp cleaner problem would be to have the emacsserver binary periodically wake up every so often, and try touching the containing directory and socket. If they have disappeared, the binary could recreate them.) Another thought --- if we're willing to bag backwards compatibility altogether, a friend recently pointed me at the existence of another package, gnuserv/gnuclient, which does most of what I had wanted. It is completely non-backwards compatible with emacslcleint --- indeed, because it uses the same variable and function names as server.el, it cannot be loaded at the same time as server.el. However, it uses s-expressions for evaluating lisp expressions as well as for passing filenames to be edited, so it is cleaner than the existing emacsclient/emacsserver. It also has security features built in, and can listen on TCP ports, so you use it across the network. - Ted