From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH v3] Add systemd socket launching support Date: Fri, 01 Apr 2016 10:10:34 +0300 Message-ID: <83pou9u7md.fsf@gnu.org> References: <874mbn7kmn.fsf@mattleach.net> <871t6qkc3h.fsf@mattleach.net> <8337r6v930.fsf@gnu.org> <83y48ytpah.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1459494667 15040 80.91.229.3 (1 Apr 2016 07:11:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2016 07:11:07 +0000 (UTC) Cc: matthew@mattleach.net, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 01 09:11:02 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1altET-0006P7-QM for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2016 09:11:01 +0200 Original-Received: from localhost ([::1]:36312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1altET-0007WU-8K for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2016 03:11:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1altEF-0007WP-Dw for emacs-devel@gnu.org; Fri, 01 Apr 2016 03:10:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1altEC-0005q0-6B for emacs-devel@gnu.org; Fri, 01 Apr 2016 03:10:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1altEC-0005pw-2a; Fri, 01 Apr 2016 03:10:44 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2704 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1altEB-00052j-8c; Fri, 01 Apr 2016 03:10:43 -0400 In-reply-to: (message from Stefan Monnier on Thu, 31 Mar 2016 17:22:35 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:202552 Archived-At: > From: Stefan Monnier > Cc: matthew@mattleach.net, emacs-devel@gnu.org > Date: Thu, 31 Mar 2016 17:22:35 -0400 > > >> In other similar functionality I've seen over the years, an alternative > >> was to pass the fd as an additional argument on the command line, but in > >> any case whether it's received from the environment or the command line, > >> the file-descriptor to use will just be an integer, and it's already > >> exposed to Lisp. > > It's an attack vector expecting to happen, so we should try to avoid > > that. > > I'm not sure what kind of attack you're thinking about. I'm not sure myself, but I'm not a criminal, so don't ask me about the details. I just know that exposing a handle through which someone can feed Emacs any commands they want is a bad idea. > And I'm not sure how the latest patch would address it (you can > still cause Emacs to use an arbitrary FD by providing the > corresponding envvars). That'd require a more serious breach of the system's security. And anyway, that's not our problem, that's the systemd problem. If they don't protect their sockets against such attacks, they should get their act together and do it. And users should be aware of such problems with systemd, and refrain from configuring Emacs to use it, IF such problems indeed exist (I don't know if they do). But what happens inside Emacs is _our_ responsibility. > >> AFAICT, only the first part is systemd-specific, so I think it would > >> make sense to try and avoid having systemd-specific details leak to the > >> other parts. > > I agree, and the last version of the patch already does that: it only > > requires a boolean flag exposed to other APIs. > > But the process part of the patch could theoretically be used in other > contexts, fundamentally, whereas it ends up being tied to systemd, so > although it's code that can be compiled and could work regardless of > systemd, it ends up being systemd-specific since it only works when used > in the systemd-way and only if you linked with the systemd library. Do you know about any other Free software that offers similar services? If you do, by all means let's design an interface to be less specific to one of them. But if no such alternative exists, I'd rather have something with as small a signature as possible, and worry about extending that when we have a real contender.