From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Emacs RPC security (was: Emacs RPC) Date: Mon, 25 Apr 2011 12:00:57 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87d3kal0za.fsf@lifelogs.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1303750894 23153 80.91.229.12 (25 Apr 2011 17:01:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Apr 2011 17:01:34 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 25 19:01:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QEPA6-0001E6-TC for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 19:01:27 +0200 Original-Received: from localhost ([::1]:39087 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEPA6-0004Zx-BH for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 13:01:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEPA1-0004Zb-UR for emacs-devel@gnu.org; Mon, 25 Apr 2011 13:01:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEP9y-0006p8-45 for emacs-devel@gnu.org; Mon, 25 Apr 2011 13:01:21 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:39160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEP9x-0006p3-Qf for emacs-devel@gnu.org; Mon, 25 Apr 2011 13:01:18 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QEP9u-00013q-J2 for emacs-devel@gnu.org; Mon, 25 Apr 2011 19:01:14 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Apr 2011 19:01:14 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Apr 2011 19:01:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:557WQ0NOL2bJxlpDL9GKDr0/MC0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138741 Archived-At: On Sat, 23 Apr 2011 20:54:28 +0200 Lars Magne Ingebrigtsen wrote: LMI> I'm running a lot of Emacs-based servers here and there, and I LMI> communicate with them via "emacsclient --eval". But it just occurred to LMI> me that it would be much more elegant to have an `emacs-client-rpc' LMI> function, so that I wouldn't have to parse the output from emacsclient LMI> in a shell. On Mon, 25 Apr 2011 09:57:15 -0300 Stefan Monnier wrote: >> Please, please implement this securely from the start. emacsclient is >> terribly insecure and we don't need to repeat that. SM> Lars's proposal has nothing to do with the network communication level. If we're going to provide *RPC*, we should worry about security at all levels, not just at the transport level. Otherwise it's just "run any code remotely on an Emacs instance" which doesn't sound as fun, right? SM> So, please take this security issue to another thread. I've changed the subject as requested. I think RPC support needs two things: 1) authentication: the server should be able to verify the client's identity and the client should be able to verify the server's identity. This can be accomplished with SSL certificates and GnuTLS or by signing each message. 2) authorization: the server should be able to associate each client identity with only certain functions it can invoke directly. The above should work across platforms and between any two networked machines with as few external dependencies as possible. I think the GnuTLS support can handle (1), plus it can encrypt the network traffic which improves security. (2) needs to happen in the server's eval loop. Ted