From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id gAp9OaYpHmKlawAAgWs5BA (envelope-from ) for ; Tue, 01 Mar 2022 15:11:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id oGX7NaYpHmLsZQAAauVa8A (envelope-from ) for ; Tue, 01 Mar 2022 15:11:50 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7AFEE429F6 for ; Tue, 1 Mar 2022 15:11:50 +0100 (CET) Received: from localhost ([::1]:50552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nP3ED-0002sC-7m for larch@yhetil.org; Tue, 01 Mar 2022 09:11:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nP34k-0005ab-S6 for guix-patches@gnu.org; Tue, 01 Mar 2022 09:02:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41999) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nP34k-0003Ml-GW for guix-patches@gnu.org; Tue, 01 Mar 2022 09:02:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nP34k-00039M-Dw for guix-patches@gnu.org; Tue, 01 Mar 2022 09:02:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#54205] [PATCH v2] Factor out a public FORK-AND-CALL. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 01 Mar 2022 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54205 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Attila Lendvai Cc: 54205@debbugs.gnu.org Received: via spool by 54205-submit@debbugs.gnu.org id=B54205.164614328412054 (code B ref 54205); Tue, 01 Mar 2022 14:02:02 +0000 Received: (at 54205) by debbugs.gnu.org; 1 Mar 2022 14:01:24 +0000 Received: from localhost ([127.0.0.1]:35896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nP347-00038L-Kb for submit@debbugs.gnu.org; Tue, 01 Mar 2022 09:01:23 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:16718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nP346-00038D-D6 for 54205@debbugs.gnu.org; Tue, 01 Mar 2022 09:01:23 -0500 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4K7JnW2Jb3z1LWpZ; Tue, 1 Mar 2022 15:01:19 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4K7JnW2Jb3z1LWpZ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1646143279; bh=l1uGHvUzUUbOqx04tjAAg3yxzMWTrX8jwCZqN7LxEDI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=nMhfkjzu2cLJ6Lhvyxh1MHKnVKfvzjKK4BGbeW8HhQR12Y3D2vEcO2H21v0wQiYpV GjTP5V9ZTgDjbPNJgSlycYUW5X8GloabdZMgcA7h8qsAiZUsERZjd1hcW+/8r6murE om7nbnqd2CXqs/3daJnMMqMSDQKBySIog4NjX4io= Message-ID: <240241970295ff5351378c915461eea180cc79d5.camel@ist.tugraz.at> From: Liliana Marie Prikler Date: Tue, 01 Mar 2022 15:01:18 +0100 In-Reply-To: References: <20220301072927.26525-1-attila@lendvai.name> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1646143910; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=l1uGHvUzUUbOqx04tjAAg3yxzMWTrX8jwCZqN7LxEDI=; b=r1giFTFsDagSCTLLE6NFQ8MGawB7Iyk23xfOY5UqCV682fNUR8mfbQokWwBlUyw+Ah66bR +Gm+sBY2W4M07kW+/EfbM3kDJVNzWT0tbKQGje0QTGRudg8vRsJl+KlaC6kiZmu/BkHIQr nT/BIWHOHbP0nGw1p47wwdRy8O0ukFdg99cZUf9tJlqT9RNqRZUmpuFL8ykNxv913HtUVa ozuZxoqi7eR00EmluWQxKAIb8kNxFYCSArNT3YgsdFF04RiM+uaaeoERMbFq/Gup5AQog/ TzirXl7rEkszKDozLoaul/q0JSnBOW42z4QpK3DLRw7DAsGHoDUdXGMhLtC7kw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1646143910; a=rsa-sha256; cv=none; b=AHkUiUc51uL01o3MSH+eFn3NVgmrjpFEtYJI5IjkEwGwRPXomXV7cB6xZ/8/NyC0MITki+ kemmhZDOGghLlydzsan02E2ok5YhV+MnrwW7d2emWDK1+aRLnr1YWXFk3Q7I7nlo19m38+ +1G6WjOp0qfT65aF7HfcsWwRXYTEeJpeHrblz7wLCTvyxNzSaBPgUoxg+WqZQDIU90eut5 +BKTlzJw/2K4tI5P2gnCcVwnqn9do7zyRCfi2qAjN01J6qi4p49CDyio2McWuajcxEmVLh 5jNTAH5oWv1EvCeJJK1Ej27yL18KNADBL9/CwyWBC24WWK2S/5CHr3E2CyvUoQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=nMhfkjzu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.61 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=nMhfkjzu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 7AFEE429F6 X-Spam-Score: 5.61 X-Migadu-Scanner: scn1.migadu.com X-TUID: 42Fhtoe7Iq6t Am Dienstag, dem 01.03.2022 um 13:04 +0000 schrieb Attila Lendvai: > > In general, I think such capabilities should be added to exec- > > command, rather than resorting to a lambda. It takes a little while > > to realize that call-in-fork, fork-and-call or whatever you want to > > name it is in fact not pure evil; mainly because shepherd could in > > its stead already invoke any lambda you throw at it. That being > > said, one should always be aware that this child process runs with > > the full permissions of shepherd, which you normally don't want to > > do for a service. > > > does the above mean that you're concerned about the security > implications? if so, then i don't understand, because Guile already > allows calling/accessing private functions/symbols, and thus this > change doesn't really increase the (already enormous) attack surface > in the guile codebase. This attack surface is less enormous if you consider the average case of a shepherd service in which the arguments to fork+exec-command are already evaluated by the time the procedure is call and thus both "sane" within and without the fork. Most of the time people are not too conscious about the fact that shepherd can already run arbitrary Guile code as part of actions and you typically only use that to its fullest extent when you're trying to do something real clever. > it does increase the shoot-oneself-in-the-foot-surface a little bit, > though. > > it's worth pointing out, though, that trusting a channel, and adding > a shepherd service defined by it to the machine's config, is > essentially giving root access to the channel author. and this is > already the case, prior to my change. > > BTW, can i not already simply pass 0, or "root" as #:user to EXEC- > COMMAND? Only if you're already root, i.e. this won't work for user shepherds, which can't become root (easily). On the other hand, I did get my user shepherd to launch pkexec commands, so that's that. > > > In my opinion, it ought to be > > > > > +(define* (fork+apply proc . args) > > [...] > > > > WDYT? > > makes sense, i'll update the patch... but given the feedback from the > two of you, should i? > > i think i'll abandon this, and implement Maxime's #:rlimits > suggestion. > > i'm not sure how much better that will be, but at least it won't make > future threading harder, and allows me to make progress with my > project. > > if anyone prefers the FORK+APPLY version, then do speak up! FWIW Maxime's complaint would also hold w.r.t. fork+exec-command, which would then be implemented in terms of fork+apply, so assuming that fork+exec-command still exists after the switch to multiple threads, we'd have to patch at least one location either way. fork+apply could make it so that less hacks are required overall to make all forking behaviour inside shepherd services as intended, but that's so far only a theoretical claim with no evidence to back it up. I think the real question is what you are trying to achieve here. If you only want to add rlimits, that's an exec-command thing. If you instead wanted to spawn a Guile function within a sandbox (rather than a completely new command), that would require something along the lines of fork+apply at least under the hood. With the things you've described, I don't think it makes sense (yet) to export fork+apply, but it might still make sense to refactor fork+exec-command under the hood. Cheers