From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id AHfVMDA/32I3OAAAbAwnHQ (envelope-from ) for ; Tue, 26 Jul 2022 03:11:12 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id qLCyMDA/32KLNgAAauVa8A (envelope-from ) for ; Tue, 26 Jul 2022 03:11:12 +0200 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 5444D39C08 for ; Tue, 26 Jul 2022 03:11:12 +0200 (CEST) Received: from localhost ([::1]:58306 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oG96N-0005rY-Cn for larch@yhetil.org; Mon, 25 Jul 2022 21:11:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oG95Z-0005qs-5X for guix-devel@gnu.org; Mon, 25 Jul 2022 21:10:21 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:38188) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oG95W-0004w4-TN for guix-devel@gnu.org; Mon, 25 Jul 2022 21:10:20 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 5FF7562A37; Tue, 26 Jul 2022 01:10:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1658797815; bh=hZM26NayrOXa0IRllg4cnAfByE+AHrgtZibb5g3qRvs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a0F0CdWdcOAoW/yaPxXOfwTHyr13Gv31TPYRdKEz0KfG7hIT7nJy7l4eAHihHGEZf KpxsRM/nQs2kYQeq6JZ+xHWYC/r/Jqu7hY5bvfEGb0qZi9axjCymfQliodcEDYBkxF QVTj8aT9koVUDx/oPQPF2k2yFPkWjtxGyiCanPRVlzotWTN4jowWGdKsNePRktwTsa X6K1uFEFSAaY+RvD2YwMejFxcKhIplBFmVdB17IW6ONt2a/M99wM4LT44fz2mQJjn5 c/M1jrHjgND/GRL3DLW8UcJ2jYmLPnF1BGeRy4TNDIP8JCMKyLxCgi4wswY54o4DxJ ccXfGgcXfE/Sw== X-Virus-Scanned: Debian amavisd-new at emo07-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo07-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk5KB-dhp7Sd; Tue, 26 Jul 2022 01:10:14 +0000 (UTC) Received: from localhost (m83-185-33-108.cust.tele2.se [83.185.33.108]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 4D3F3629D2; Tue, 26 Jul 2022 01:10:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1658797814; bh=hZM26NayrOXa0IRllg4cnAfByE+AHrgtZibb5g3qRvs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dF4YcDhmzMbHiWnj+EJWxkBW+B7rKKxEPJ3Hxrn25CfTkbxHfT3aM6YlwtEG5o5P7 hVafViFH57G9oS8RZ76fDQm/DtjBzRTpjfqvLglA6oa+kac9chZnNOyn2ncy/GgkwP 5NPL2vqKV6B6LFgBslWZ3KCVAaLh4beNujyrIbolRnmYWd2UMhMX030tisBujNN8MT O58w0OzHAdYg57ivEhXSMZADlZkSLqzQiH+WnJJtCGy9xoelRILoQQm3kP5+Bv/tv6 wxJVph9cZeDrEt0hIM01gxjv0H8Ywk39SUSh8h45ZcJOqr83OIQ9JmyImovKehPqA/ zHjUO+EuKT0XQ== Date: Tue, 26 Jul 2022 03:09:58 +0200 From: Bengt Richter To: Josselin Poiret Cc: Zhu Zihao , guix-devel@gnu.org Subject: Re: Building, packaging and updating Guix with confidence Message-ID: <20220726010958.GA7490@LionPure> References: <87let6roxo.fsf@jpoiret.xyz> <867d4pjedm.fsf@163.com> <87h73trnyu.fsf@jpoiret.xyz> <20220717165219.GA19816@LionPure> <871quezbsi.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <871quezbsi.fsf@jpoiret.xyz> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=64.68.200.34; envelope-from=bokr@bokr.com; helo=mailout.easymail.ca X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1658797872; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=AmxdHfsjwICo+BkrItnDvjFMEH/yfyZjDsQfCuKD9Ng=; b=YPe/Q/j1ZAAYMqJQwLAt5uHtHx6cHEo1LlKoOk9CGJINk3Vin6rBqErG76Eh4dWG4XruQ/ ooF89RXg/7XZcsvH4cQ53eU/patqps0nYGWDGmUZmF5SxZVpRrUchRnrAMzQSWG7PY4ho5 0hCFHgf/MKMj91t4Ijbdzo93GsJuEWrNoBUdgsVFyt7cglmFFTxWuo6KP4xJLiIbMGb4Q7 cncAd7p2wtTgq821uRqv5heNoceS5sNGGPcaKj+FM7bTVa5sHD9yBDVpM0TU0OqScKDAPl UUSuED0t0QKbMWMNUyvMyD/NvzkofpjptL3ICS99Q22Ew5EkaAL8C+7VCPCizA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1658797872; a=rsa-sha256; cv=none; b=hu/lBmYG6f0q343LSNea5lofiKYCdP1JaEyfulwE5AID6EiwUqFhb+aojLaOvd1UiKgoiU AXsCHReRM3nA1kN7ToYPDOWHJ3uvhKQK5uhd9p/6KRYWOigZz3KKbBlr64HjyoQ4bEwIzF mbz/l2KWwPUMHilZZZ6XWxKXQh2TZdLigTbQbp9GVu9f/B+Qkvsy8J61y1iYrkpwAuhLpR evChBlNkdvlZWXYU4KQCOGbdAIZEAs3Q+vCSjcIjHHQfdmlNeYkkIddY00A5WBTTqkpTca AkmDzK0p/jDaCCe1FOYaDCJUo78mHP9ixsIKQzMgL3IQARbPziVYtfkIE/bkyw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b=a0F0CdWd; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b=dF4YcDhm; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 1.57 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b=a0F0CdWd; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b=dF4YcDhm; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 5444D39C08 X-Spam-Score: 1.57 X-Migadu-Scanner: scn1.migadu.com X-TUID: /Oup7Oyz+yyV Hi Josselin, tl;dr: I naively don't buy the rationale against a non-root guix daemon :) Skip to [2] if tl ;) On +2022-07-21 18:10:53 +0200, Josselin Poiret wrote: > Hello, > > bokr@bokr.com writes: > > Naively: > > > > Why does "the" guix daemon per se need root access at all? > > The main thing is that all files in the store end up being written by > the guix daemon user. IIUC, that would be guixrootd per se, not the homeless guixbuilder{0-10} users created by the default install, right? (IIUC the latter are meant to allow guixrootd to shed its root write privilege by spawning a user mode continuation, so to speak?) > ... So if we want the files to be easily > substitutable, they'd need to have a fixed uid/gid, Why? "Easily" in what way? untarring tarballs? Even if tar sets bogus external file system metadata, UIAM the only privilege you need is ownership, and neither guix nor the installer need to run as root themselves to get ownership. That can be done by a tiny helper whose source you can see on one page, and whose execution you can limit to a user such as the single-writer guixstored, which UIAM can then chmod and chown at will to share or not. I don't believe in blanket permissions to accomplish a tiny important priviliged action. I want to see it factored out for auditability and comprehensibility. (Here I did s/guixrootd/guixstored/ as a name for a non-root user which has exclusive control over gnu/store because it creates /home/guixstored/gnu/store thus in its home directory and no other user has write access to it except by talking to guixstored via message or sharing read-only files if mounted and reachable and permitted by guixstored setting perissions on files it owns. > ... and the only one we > can guarantee is root. But why would you have to? ISTM not necessary. > ... Other than that, it needs to use a bunch of > Linux namespaces to isolate the builds from the rest of the system, You mean like -G from --8<---------------cut here---------------start------------->8--- useradd -g guixbuild -G guixbuild${KVMGROUP} \ -d /var/empty -s "$(which nologin)" \ -c "Guix build user $i" --system \ "guixbuilder${i}"; _msg "${PAS}user added " fi --8<---------------cut here---------------end--------------->8--- YOW! running as root AND being able to do KVM stuff? My naive paranoia button has been pushed, and I don't want to do the searching for info to calm myself ;/ BTW, above snip was from guix clone repo pull as of ┌──────────────────────────────────────────────────────────┐ │ # $ git log --pretty=medium --grep 'install\.sh'|head -3 │ ├──────────────────────────────────────────────────────────┤ │ commit 3348e485b7229e062e563945ed7e6ac216f25125 │ │ Author: Philip McGrath │ │ Date: Sun Jul 3 22:35:03 2022 -0400 │ └──────────────────────────────────────────────────────────┘ > which depending on the kernel build-time configuration might not be > possible when unprivileged. > IWT think that goes away if you run a single-writer daemon on the local OS, and let the kernel use its namespaces to keep the users from trampling on each other (any more than they already maybe can with the current setup). If the OS can't separate users, ISTM everbody is kind-of root in effect, but then maybe we can run a single user thread as if root, if you have an environment where that's useful -- maybe cloud virtual pcs? Communicating would be an adapter problem, but virtual pcs can boot fully fledged linux these days, I think, and it seems doubtful that you would run a big guix build ON a raspberry pi even though TARGETING an rpi makes lots of sense. Whew, I've got to stop re-editing this :/ [2]: So, do you see any real obstacles to making guixrootd an ordinary user (in the sense of /home/ordinary_user/ ) and calling it guixstored instead, with an ordinary /home/guixstored/ home directory (where it has natural protection as guixstored:guixstored on useradd creation, with added group guixbuilder for helper r/o sharing, which as owner it can control)? However many guixbuilder0{1..9}:guixbuilder0{1..9} helper users are created, (plus guixbuilder10:guixbuilder10 in the default naming :) they would also belong to the guixbuilder extra group (no suffixed number) but they only would have read access to parts of /home/guixstored/gnu/store/... unless guixstored as owner sets other permissions for the guixbuilder group. I'm not seeing why there needs to be any guix daemon running as root :) But this means you can't just uncompress files, metadata and all, for substitution purposes, which I guess you were alluding to with "...can't easily...", right? But IWT that guixstored could use a tiny helper to get ownership, as above. Becoming owner by using a factored-out-tiny-helper to chown untarred stuff should be safer than running bigstuff as root IWT). It can then create and exclusively control /home/guixstored/gnu/store/... and allow guixbuilder{1..10} user-helpers to have group read access to /home/guixstored/gnu/store/... I am imagining smallish /home directories /home/guixbuilder{1..10}/... for those helpers to maintain their own states in whatever they are helping with, and outputting their final results to guixstored by the most efficient means available to the process. If they're on the same SOC or on the other side of the globe will make a difference, but IMO that's an adaper concern which should not affect the design of the essential guile/guix package management sources or their hashes. Well, IMHO any adaptations to particular file systems or transfer protocols should be considered as just that: adapters, orthogonal to the essential data transforming that guix/guile does, where all data is just various interpretations of #vu8 compositions. Otherwise, if adaptor cruft is incorporated into the essential guix package manager, IMHO it will grow into a rube-goldberg kludge-ball. Let it manage libraries of adapter implementations, but keep them scrupulously outside, along with the definitions of their dependencies on the metadata describing what they are adapting to. I think basically everything guix/guile reads and writes as it does its package management should have an official documented #vu8 representation. Including snarfed and transformed foreign metadata. > Best, > -- > Josselin Poiret For reference, this is a remnant from an old install, but I assume this is still what the intaller creates (right?). ┌─────────────────────────────────────────────────────────────────────────┐ │ # $ grep guix /etc/passwd │ ├─────────────────────────────────────────────────────────────────────────┤ │ guixbuilder01:x:998:998:Guix build user 01:/var/empty:/usr/sbin/nologin │ │ guixbuilder02:x:997:998:Guix build user 02:/var/empty:/usr/sbin/nologin │ │ guixbuilder03:x:996:998:Guix build user 03:/var/empty:/usr/sbin/nologin │ │ guixbuilder04:x:995:998:Guix build user 04:/var/empty:/usr/sbin/nologin │ │ guixbuilder05:x:994:998:Guix build user 05:/var/empty:/usr/sbin/nologin │ │ guixbuilder06:x:993:998:Guix build user 06:/var/empty:/usr/sbin/nologin │ │ guixbuilder07:x:992:998:Guix build user 07:/var/empty:/usr/sbin/nologin │ │ guixbuilder08:x:991:998:Guix build user 08:/var/empty:/usr/sbin/nologin │ │ guixbuilder09:x:990:998:Guix build user 09:/var/empty:/usr/sbin/nologin │ │ guixbuilder10:x:989:998:Guix build user 10:/var/empty:/usr/sbin/nologin │ │ guixrootd:988:998:Guix root daemon:/home/guixrootd: │ └─────────────────────────────────────────────────────────────────────────┘ So WDYT? :) -- Regards, engt Richter