From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH v3] Add systemd socket launching support Date: Thu, 31 Mar 2016 17:22:35 -0400 Message-ID: References: <874mbn7kmn.fsf@mattleach.net> <871t6qkc3h.fsf@mattleach.net> <8337r6v930.fsf@gnu.org> <83y48ytpah.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459459374 6176 80.91.229.3 (31 Mar 2016 21:22:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 21:22:54 +0000 (UTC) Cc: matthew@mattleach.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 31 23:22:46 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 1alk3B-00005O-T5 for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2016 23:22:46 +0200 Original-Received: from localhost ([::1]:34488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alk3B-0001ew-6Y for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2016 17:22:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alk37-0001eW-Dm for emacs-devel@gnu.org; Thu, 31 Mar 2016 17:22:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alk36-0000aQ-Hd for emacs-devel@gnu.org; Thu, 31 Mar 2016 17:22:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alk32-0000ZR-Kl; Thu, 31 Mar 2016 17:22:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+FgA731xV/0+KpUVcgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIxALNBIUGA0kiDcIzyMBAQEBBgIBH4s6hQUHhC0Fsz+BRSNhgQWCLiKCeAEBAQ X-IPAS-Result: A0A+FgA731xV/0+KpUVcgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIxALNBIUGA0kiDcIzyMBAQEBBgIBH4s6hQUHhC0Fsz+BRSNhgQWCLiKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="204318149" Original-Received: from 69-165-138-79.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.79]) by ironport2-out.teksavvy.com with ESMTP; 31 Mar 2016 17:22:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 16FE963FC5; Thu, 31 Mar 2016 17:22:35 -0400 (EDT) In-Reply-To: <83y48ytpah.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 31 Mar 2016 22:34:14 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:202532 Archived-At: >> 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. 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). >> 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. Stefan