From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for system accounts in a container Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 31 Dec 2020 18:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 45571@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.160943875717476 (code B ref -1); Thu, 31 Dec 2020 18:20:01 +0000 Received: (at submit) by debbugs.gnu.org; 31 Dec 2020 18:19:17 +0000 Received: from localhost ([127.0.0.1]:41525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kv2Xd-0004Xo-Az for submit@debbugs.gnu.org; Thu, 31 Dec 2020 13:19:17 -0500 Received: from lists.gnu.org ([209.51.188.17]:60580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kv2Xb-0004Xg-TM for submit@debbugs.gnu.org; Thu, 31 Dec 2020 13:19:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kv2Xb-0003yr-ND for bug-guix@gnu.org; Thu, 31 Dec 2020 13:19:15 -0500 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:36821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kv2XZ-0004CN-EO for bug-guix@gnu.org; Thu, 31 Dec 2020 13:19:15 -0500 Received: by mail-ej1-x62e.google.com with SMTP id lt17so26168522ejb.3 for ; Thu, 31 Dec 2020 10:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LtBLNe1u7Po84ipNzLXPJ2PnK8rKI3/3E1wWolvxL/I=; b=fPJ1GNG1Qi+VVhORWhtSiB5HM/B7HtFQ/D3JI/LF77C6LcpCG101OGp07MfbMzJliI xcFLWcpElYceOO9+bDLi4qwld9QkXo/EM6ck1wqwG8cT+QSXmTwi+lLriXvJyewFqCsX y3V65xhRRmLExdJitPOeKCidsqoR2m+zJjRyXKIfcT5BpEZT7t64FrQvxILOlLiWQEio q4ZOZJHJLrD7Sw6iVepug6R4O37gg8JEWSSq7iUfyFXs9UAtSq7X2QOLip/X3a/Q98an vD6xpWCo429AlwBeqmiAh19WywdcEmQH5m65qerL0vg1B1Cqe5r3nBK5EyaIl+XO24V6 SMFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LtBLNe1u7Po84ipNzLXPJ2PnK8rKI3/3E1wWolvxL/I=; b=Fbii54S3whnhFxbkrqLG4LfhXd6BZwb3OFPf5/k+dqFwqk78mbWIPmd0EuCFFdhOb7 +lNviICRJtjBf9NVhOxzYzO/rB9DMwO216wRvZ5iK9qf4PjuURPgBnAVWA9Me8o9yL6t ZD8NHGlVtUNncdYhA8UVKIedoPlCxs5m0YsgADy6nwTVHmWAHbUgUcZSGRk8BPr9DKLt KgGe3VK/cy4uOS/FRTluw0cYXVvJxzCfYqA6Jo+5VKJ6lHor/NiEgA+jlYWZMt3jLDgG bHSGVcq3jxUebL9Qq/p5Ma06BLdv+GGEToqQ7Ta23vmCTDjWhdl6Lkz71QcyC8/5d6+k IoJw== X-Gm-Message-State: AOAM532ZgWy5F3cLMiNxhR7MMylrcPp8jp9JSF2R0J4/oY5vHakmJwnk BnKzRAZy47oq2p7Zngw3sEF0/tVvRXN/CiLfvsD+4Zy2e+w= X-Google-Smtp-Source: ABdhPJyi5hovR+02AUPUY/EhSYYT7HJTHssQwnzi0n3RRFLZCl8mbV36Q0OArCXfuH+6r52DrN0KWY3w7HRr1z/g0FA= X-Received: by 2002:a17:907:435c:: with SMTP id oc20mr55408939ejb.286.1609438751801; Thu, 31 Dec 2020 10:19:11 -0800 (PST) MIME-Version: 1.0 From: Jason Conroy Date: Thu, 31 Dec 2020 13:18:36 -0500 Message-ID: Content-Type: multipart/alternative; boundary="00000000000016c49b05b7c6a996" Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=conjaroy@gmail.com; helo=mail-ej1-x62e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --00000000000016c49b05b7c6a996 Content-Type: text/plain; charset="UTF-8" If I understand correctly, the container script produced by "guix system container" will allocate the same uid and gid for a service on each execution, but only if the corresponding entry in the service list has the same absolute position as it did before. I.e., if the services are reordered or if there are additions and removals, it's unlikely that the id allocations will be the same. As long as a container's filesystems don't outlive the container itself, this works fine. But when host filesystems are bind-mounted inside the container with the --share or --expose options, it's important that each incarnation of a service uses the same uid and gid, because the bind mounts might be used to hold persistent state for those services. At first, I thought that I could just define static uids and gids for these system accounts by adding corresponding user-account and user-group entries. But this doesn't work: rather than changing how the system accounts are defined for these services, it results in /etc files with duplicate entries. (See https://issues.guix.gnu.org/45570 for details.) --00000000000016c49b05b7c6a996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I understand correctly, the container script produ= ced by "guix system container" will allocate the same uid and gid= for a service on each execution, but only if the corresponding entry in th= e service list has the same absolute position as it did before. I.e., if th= e services are reordered or if there are additions and removals, it's u= nlikely that the id allocations will be the same.

= As long as a container's filesystems don't outlive the container it= self, this works fine. But when host filesystems are bind-mounted inside th= e container with the --share or --expose options, it's important that e= ach incarnation of a service uses the same uid and gid, because the bind mo= unts might be used to hold persistent state for those services.

At first, I thought that I could just define static uids = and gids for these system accounts by adding corresponding user-account and= user-group entries. But this doesn't work: rather than changing how th= e system accounts are defined for these services, it results in /etc files = with duplicate entries. (See = https://issues.guix.gnu.org/45570 for details.)


--00000000000016c49b05b7c6a996-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 14:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Jason Conroy Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160951251512808 (code B ref 45571); Fri, 01 Jan 2021 14:49:01 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 14:48:35 +0000 Received: from localhost ([127.0.0.1]:60309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvLjG-0003KT-Oj for submit@debbugs.gnu.org; Fri, 01 Jan 2021 09:48:34 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:52972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvLiG-0003Cw-Ot for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 09:47:33 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 1638F3362EF8; Fri, 1 Jan 2021 15:47:31 +0100 (CET) Date: Fri, 1 Jan 2021 15:47:28 +0100 From: Danny Milosavljevic Message-ID: <20210101154504.28a18674@scratchpost.org> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Z/k7LrfZ2VSyz7UEzumfASL"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/Z/k7LrfZ2VSyz7UEzumfASL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, I agree that user ids and group ids should be made stable, even in general. I, too, have been bitten by this. (So would everyone else if Guix touched existing UNIX accounts in general) The right way to make them stable is for Guix ot default each uid to the ha= sh of the user name. That said, we'd want to leave free some range of the integer uids for the u= sual suspects (yp, samba) to allocate domain users there. The place to change is gnu/system/accounts.scm. It would need to be changed to do something similar for the "uid" field that it already does for the "home-directory" field. According to the source code of "useradd" in the package "shadow", it uses the following range to use for automatic uid assignment: Range starts at SYS_UID_MIN (default 1) for system user account uids, and s= tops at SYS_UID_MAX (default (UID_MIN - 1)). =20 For non-system user account uids, it starts at UID_MIN (default 1000) and stops at 60000 (UID_MAX). See /etc/login.defs for the configured values. Note that Linux has no problem using 32 bit uids. If we want to make it possible for Guix to distinguish system from non-syst= em accounts by having different uid ranges for each, "system?" in the record would need to be moved to the front. Then, in order to be backward compatible, custom procedures/macros "make-user-account" and "user-account" would need to be provided with the parameters in the previous order. Should not be difficult to do--as always, the main work is in agreeing what should be done, and in testing it after it's done. The actual change is li= ke 10 lines of source code. (An easier workaround would be to make the uid mandatory, with the default being failure. But that would be the "punting" solution) --Sig_/Z/k7LrfZ2VSyz7UEzumfASL Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vNgAACgkQ5xo1VCww uqWm/Qf7BKjeacyamWrwQD+Jcs9/iRyRbQKhRYks2uG7PbLGVsLs8j0Vv0cLGKVu IVp/22wuhs0gbwNul3lAHOaYIO1EuawaOwmIGlFt0SywSbzGfMPjPUpfVKwKsOLC rzFAQcaZgWiwOz2urPhJEONm47q6uKGCuHLqGoV58ABEFS5r/RhV/xWlSBPva+dD EX/nslH1SJB2/LHZV0UfwXD8yDOYmygYFiPDoInYf9rEZJ9DBX+jEjZtyI3i8Kzw hjWhTk7YFxcSAi0HaRRYmzVJDy99EiW/TAW4C4ThVmVws+6jP//+xdVVilYgbwey i9V78V86uC3y9uQ3oH3R3CJdmscKZQ== =FyvA -----END PGP SIGNATURE----- --Sig_/Z/k7LrfZ2VSyz7UEzumfASL-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts References: Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 16:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: dannym@scratchpost.org Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160951806625714 (code B ref 45571); Fri, 01 Jan 2021 16:22:02 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 16:21:06 +0000 Received: from localhost ([127.0.0.1]:34598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvNAo-0006gf-3b for submit@debbugs.gnu.org; Fri, 01 Jan 2021 11:21:06 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:44778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvNAk-0006fo-BT for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 11:21:04 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D6qyN05ztz1LBSH; Fri, 1 Jan 2021 17:20:59 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D6qyN05ztz1LBSH DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609518060; bh=qSmmaxS18K5Ohfh9Ag/4eWgJ+Eg6qSI/7uiP4KQSRzU=; h=Subject:From:To:Cc:Date:In-Reply-To:From; b=MnsqEqGhqSHyZPYG/LF2Bd+IO9yv2euT5xYXLQqPmXcocFPWksASB2wO9AQAJvxeP LtYX62HlKvnCJvXfC+IZ8wYLGZu/MlVcZ0m+QApL8+cMN9DQ06nqSgJThcbDEtVfyc R2f07h6+WS4JDeSJve4DGgJCD2gyg/z1eergZDpI= Message-ID: From: Leo Prikler Date: Fri, 01 Jan 2021 17:20:58 +0100 In-Reply-To: 20210101154504.28a18674@scratchpost.org Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello Danny, I don't think changing the way UIDs are allocated by default is a good solution as that will break many running installations on real hardware, that default to those. A better solution would be to make user accounts and groups explicit configuration wherever account- service-type is used, so that it's possible to override them if needed. Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 16:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160951842126254 (code B ref 45571); Fri, 01 Jan 2021 16:28:01 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 16:27:01 +0000 Received: from localhost ([127.0.0.1]:34606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvNGX-0006pH-1I for submit@debbugs.gnu.org; Fri, 01 Jan 2021 11:27:01 -0500 Received: from mail-ej1-f43.google.com ([209.85.218.43]:40392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvNGV-0006p5-Tb for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 11:27:00 -0500 Received: by mail-ej1-f43.google.com with SMTP id x16so28396172ejj.7 for <45571@debbugs.gnu.org>; Fri, 01 Jan 2021 08:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JcTq9N6sfK7nT3UeXtxAV7VLssPEyZiyVruacZv63nM=; b=e3z2QbdvccjVf3V6076uZS4S1g0JcOzDgFsQ6RYaFQbJfaHdXOwR/j2dBr6YnSw5Pk 8H/CBx1GyEToctY+yYvOgf2qH/gX4iEv3OXMIxhO07UewJ1dt7KrvPmQVJQ2Y3jLd14V eSRRuKKntPGjue11XG4VjW5mYm+lbdQ+zuGpcSUDIoYn0Y8x28OwhnjkgnmecYXuqiVN 9azHdkU4HCyxE7PkPpXE4oFrzrWNpGrQPrW1fiiG9jEkNZmetdpwFF3lDEFTVmCuA7+o ia4AksLxoTAdyz23KF/K9g7jfPfu0Squb8y7pcEVVYC9RfYCFcH9XvOTwaLLgSVDIHLN E22A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JcTq9N6sfK7nT3UeXtxAV7VLssPEyZiyVruacZv63nM=; b=eBfUHALkK/IVjqSjZcj1Q1vqmwxsY7EvLejSn5LGtVG/ZVRuGd0et9mqxfB17s4E8e WPgHCoEUtq0BK3HBosl+iJvQIm9ZAGrpbudkrR0yBnoBsf1UHdHwYjUZUz80BhRT7poK yEJahaolOG516HY+DiFvvPuTWodCFq2hzk6yHt1ji6cXJRzb9BslODVrFysBMVWDH1Fd nJUAWubcuJm8PT8cP2hb4TC9Akk6z9DrZclnRH70XwPyRcqVva8MRGjfwKF8RoGJEg8V YR9OOW8ajBx/+AcbHpgF71gbRgQTx0b0JJkAx+bFPQQMKuAdO0MAfZZmP4lBDKN8c4ru DyOA== X-Gm-Message-State: AOAM533UI4KTWnk3v8PqGP7lgpdaBKMj0mvJ+CClDQiqpg0Zpn1rVfyo TaNBfSRKCnshr3fJpTQ6d5T/ry3tBuRSPSIVJ/A= X-Google-Smtp-Source: ABdhPJwuVvA/xkB2ZuTlhtAB24F6Y40IYOrcXP5+7w2vwTGl2Z5N337nnNY1ywyyxnNnAbFInlHZSiMEkqV87yEskL8= X-Received: by 2002:a17:907:435c:: with SMTP id oc20mr58801238ejb.286.1609518414115; Fri, 01 Jan 2021 08:26:54 -0800 (PST) MIME-Version: 1.0 References: <20210101154504.28a18674@scratchpost.org> In-Reply-To: <20210101154504.28a18674@scratchpost.org> From: Jason Conroy Date: Fri, 1 Jan 2021 11:26:18 -0500 Message-ID: Content-Type: multipart/alternative; boundary="0000000000005535ac05b7d9359b" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000005535ac05b7d9359b Content-Type: text/plain; charset="UTF-8" Hi Danny, Your idea has a definite elegance to it. :) I did not realize that Linux supported 32-bit UIDs out-of-the-box. Still, I wonder if this could introduce support challenges for packages that incorrectly assume UIDs are 16 bits wide, since they traditionally were that way in UNIX, and since other Linux distros still seem to prefer small UIDs in their packaging. By comparison, my earlier idea of declaring static UIDs/GIDs in the operating-system is decidedly less elegant, but it avoids this particular risk. Can we be confident that this class of integer width bugs is extremely rare? On Fri, Jan 1, 2021 at 9:49 AM Danny Milosavljevic wrote: > Hi, > > I agree that user ids and group ids should be made stable, even in general. > > I, too, have been bitten by this. (So would everyone else if Guix touched > existing UNIX accounts in general) > > The right way to make them stable is for Guix ot default each uid to the > hash > of the user name. > > That said, we'd want to leave free some range of the integer uids for the > usual > suspects (yp, samba) to allocate domain users there. > > The place to change is gnu/system/accounts.scm. It would need to be > changed > to do something similar for the "uid" field that it already does for the > "home-directory" field. > > According to the source code of "useradd" in the package "shadow", it uses > the following range to use for automatic uid assignment: > > Range starts at SYS_UID_MIN (default 1) for system user account uids, and > stops > at SYS_UID_MAX (default (UID_MIN - 1)). > > For non-system user account uids, it starts at UID_MIN (default 1000) and > stops at 60000 (UID_MAX). > > See /etc/login.defs for the configured values. > > Note that Linux has no problem using 32 bit uids. > > If we want to make it possible for Guix to distinguish system from > non-system > accounts by having different uid ranges for each, "system?" in the > record would need to be moved to the front. > Then, in order to be backward compatible, custom procedures/macros > "make-user-account" and "user-account" would need to be provided with the > parameters in the previous order. > > Should not be difficult to do--as always, the main work is in agreeing what > should be done, and in testing it after it's done. The actual change is > like > 10 lines of source code. > > (An easier workaround would be to make the uid mandatory, with the default > being failure. But that would be the "punting" solution) > --0000000000005535ac05b7d9359b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Danny,

Your idea has= a definite elegance to it. :) I did not realize that Linux supported 32-bi= t UIDs out-of-the-box. Still, I wonder if this could introduce support chal= lenges for packages that incorrectly assume UIDs are 16 bits wide, since th= ey traditionally were that way in UNIX, and since other Linux distros still= seem to prefer small UIDs in their packaging. By comparison, my earlier id= ea of declaring static UIDs/GIDs in the operating-system is decidedly less = elegant, but it avoids this particular risk. Can we be confident that this = class of integer width bugs is extremely rare?

On Fri, Jan 1, 2021= at 9:49 AM Danny Milosavljevic <dannym@scratchpost.org> wrote:
Hi,

I agree that user ids and group ids should be made stable, even in general.=

I, too, have been bitten by this.=C2=A0 (So would everyone else if Guix tou= ched
existing UNIX accounts in general)

The right way to make them stable is for Guix ot default each uid to the ha= sh
of the user name.

That said, we'd want to leave free some range of the integer uids for t= he usual
suspects (yp, samba) to allocate domain users there.

The place to change is gnu/system/accounts.scm.=C2=A0 It would need to be c= hanged
to do something similar for the "uid" field that it already does = for the
"home-directory" field.

According to the source code of "useradd" in the package "sh= adow", it uses
the following range to use for automatic uid assignment:

Range starts at SYS_UID_MIN (default 1) for system user account uids, and s= tops
at SYS_UID_MAX (default (UID_MIN - 1)).

For non-system user account uids, it starts at UID_MIN (default 1000) and stops at 60000 (UID_MAX).

See /etc/login.defs for the configured values.

Note that Linux has no problem using 32 bit uids.

If we want to make it possible for Guix to distinguish system from non-syst= em
accounts by having different uid ranges for each, "system?" in th= e
<user-account> record would need to be moved to the front.
Then, in order to be backward compatible, custom procedures/macros
"make-user-account" and "user-account" would need to be= provided with the
parameters in the previous order.

Should not be difficult to do--as always, the main work is in agreeing what=
should be done, and in testing it after it's done.=C2=A0 The actual cha= nge is like
10 lines of source code.

(An easier workaround would be to make the uid mandatory, with the default<= br> being failure.=C2=A0 But that would be the "punting" solution)
--0000000000005535ac05b7d9359b-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 17:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Jason Conroy Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.1609522609512 (code B ref 45571); Fri, 01 Jan 2021 17:37:01 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 17:36:49 +0000 Received: from localhost ([127.0.0.1]:34717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvOM5-00008C-0p for submit@debbugs.gnu.org; Fri, 01 Jan 2021 12:36:49 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:34420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvOM2-000082-NC for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 12:36:48 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id E06843363807; Fri, 1 Jan 2021 18:36:43 +0100 (CET) Date: Fri, 1 Jan 2021 18:36:37 +0100 From: Danny Milosavljevic Message-ID: <20210101183637.6ff62412@scratchpost.org> In-Reply-To: References: <20210101154504.28a18674@scratchpost.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/iIhj5cxIiZ7J/Hc92CzLmLW"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/iIhj5cxIiZ7J/Hc92CzLmLW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jason, >Still, I wonder if this could introduce support challenges for packages th= at >incorrectly assume UIDs are 16 bits wide, since they traditionally were th= at >way in UNIX, I don't think that these 16 bit problems are common at all since all the getuid() syscalls I've ever seen, even in traditional UNIXes, have "int" as return value--and nowadays that's at least 32 bits; and also because UNIX configuration is usually in text files, which would read and store the stuff using "%d". That said, it's possible that it could happen in some seriously strange configurations (I doubt it). > and since other Linux distros still seem to prefer small UIDs in > their packaging. By comparison, my earlier idea of declaring static UIDs/= GIDs > in the operating-system is decidedly less elegant, but it avoids this par= ticular > risk.=20 If we did something like that, I would prefer for guix services to just spe= cify a fixed UID/GID for each of the entries in gnu/services/*.scm. We can even reuse existing system uids and gids that have been statically allocated already by FreeBSD and Debian and be even uid/gid compatible to those. For example, change Guix to do (similarly for all Guix services using user accounts): diff --git a/gnu/services/monitoring.scm b/gnu/services/monitoring.scm index 5123a8c441..45d3f4ad17 100644 --- a/gnu/services/monitoring.scm +++ b/gnu/services/monitoring.scm @@ -71,6 +71,7 @@ =20 (define %darkstat-accounts (list (user-account + (uid 4711) (name "darkstat") (group "darkstat") (system? #t) @@ -78,6 +79,7 @@ (home-directory "/var/lib/darkstat") (shell (file-append shadow "/sbin/nologin"))) (user-group + (id 4711) (name "darkstat") (system? #t)))) And other constants for other user names. Or use hashes. Whichever. The point is that the ids are deterministic--not necessarily that we need to use hashes. The advantage of using a hash is t= hat we don't need a central registry and this problem will be out of our life o= nce and for all. Anyway, as a workaround for your immediate problem, I suggest to preserve /etc/passwd, /etc/group and /etc/shadow--present entries in those will be preferred by Guix to even its own configuration. (I'm not sure whether tha= t's currently easy to do with guix system container, however) --Sig_/iIhj5cxIiZ7J/Hc92CzLmLW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vXaUACgkQ5xo1VCww uqV4twf/SE9DMqS+8viTnEak25kEV7V5xCU7eRyiBDqI1XyrXuL55Si03mkCrmbI gbP0EC7/qR4JDyapRyoAlVif4Z0R9zgVD4jBxDi/8Sz7+mjnvwj1KfMxCIeQhbqg FcGiO5smE1yQHupNXWkTW04dzqzgl3FP0vQtAcAHht1z3Hc0REHfhNJ/aYu6GbyQ YdcPh7qBL9gY1B1CY2Ap0pdoFF4pFEDUYCg3lW4VWKwCngmCD+D0mifxevXLAjix b9Z/lh+4nkQJvzoHssZJLFGHdhsLBXyvR5ok+7bWM0er0z1+ChYoAsVhCOTQVM13 8lSeASGEFMcrt7X5bqL71f6WSwKn8g== =SB/f -----END PGP SIGNATURE----- --Sig_/iIhj5cxIiZ7J/Hc92CzLmLW-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095234191793 (code B ref 45571); Fri, 01 Jan 2021 17:51:02 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 17:50:19 +0000 Received: from localhost ([127.0.0.1]:34753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvOZ9-0000Sr-HD for submit@debbugs.gnu.org; Fri, 01 Jan 2021 12:50:19 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:35238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvOZ7-0000Se-H0 for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 12:50:18 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 17816336521B; Fri, 1 Jan 2021 18:50:16 +0100 (CET) Date: Fri, 1 Jan 2021 18:50:12 +0100 From: Danny Milosavljevic Message-ID: <20210101184838.21869359@scratchpost.org> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/4F9etEZHa5OAgo_R2mI+fjA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/4F9etEZHa5OAgo_R2mI+fjA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, On Fri, 01 Jan 2021 17:20:58 +0100 Leo Prikler wrote: > I don't think changing the way UIDs are allocated by default is a good > solution as that will break many running installations on real > hardware, that default to those. =20 (gnu build accounts), allocate-passwd defaults to keep using the uids of existing /etc/passwd entries. So running installations on real hardware will not be affected when we change the defaults--otherwise those installations on real hardware would already have had big problems regarding user accounts with the current version of Guix when someone adds a user acc= ount (system account or not) to them. Then, depending on the order of the decla= red user-accounts, the uids would have swapped. >A better solution would be to make > user accounts and groups explicit configuration wherever account- > service-type is used, so that it's possible to override them if needed. They already are explicit. For example, (gnu services monitoring) has: >(define %darkstat-accounts > (list (user-account > (name "darkstat") > (group "darkstat") > (system? #t) > (comment "darkstat daemon user") > (home-directory "/var/lib/darkstat") > (shell (file-append shadow "/sbin/nologin"))) > (user-group > (name "darkstat") > (system? #t)))) and then > (extensions > (list (service-extension account-service-type > (const %darkstat-accounts)) As you can see, the user and group accounts are already explicit. What's more, the uid (and group id) can already be specified right there, and I argue that it should be specified right there, and that there should be a stable default if it's not specified. So to summarize: (1) This bug is a real problem, and something should be done about it. (2) The reason it doesn't currently affect Guix system users is because the= re is logic preferring existing /etc/passwd, /etc/shadow and /etc/group entries (which I agree is a good idea). Doesn't help for guix system container, th= ough. Or for NFS network file systems. Any time you have more than one computer (even with Guix on it) with a filesystem in the network and regular users, you have to have consistent uids or have a lot of weird uid maps per comput= er that someone has to maintain, or worse, an extra service just mapping them. Why do that to yourself? (3) For /etc/shadow, it also makes sense to keep the existing entry (the us= er name is the key for the search for it btw) because of the password set. (4) It makes sense to keep the existing /etc/{passwd,shadow,group} entries = both for backward compatibility and also for extensibility of guix with user & g= roup accounts guix knows nothing about. (5) Also for not having this bug with containers, it would still be better = to just make uid and gid mandatory for "user-account" records. (6) Since (5) would move the burden to the user, it would be better usabili= ty to generate uid and gid in a deterministic manner as a default. Both (5) and (6) can be done even now without problems because of (2). --Sig_/4F9etEZHa5OAgo_R2mI+fjA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vYNQACgkQ5xo1VCww uqXjIgf/a3oYUVFXIxWvOQuPlfCUIqmNducup/1Ak0xgM7vc5NYdxFfLef1FResi l3meMnL4ZbmECInGrQ9NicXPuod94wU30wHc20dB3ZvGxgifqvyXaKi8fo+oruEb e8GVi8jS+MzypsrzF0sGihb0DUHI54TCvFhUZAg3pXeZPgK/9P/5NXbQEhsqnEuU IbBcufV5YrzI6ngpDERyfIikIblJhhP7EgDiSJd6rcRRTN9bkvuKD97lcDK1RVe2 hioRw/G7ic5EvDJ2gKucaT6YIHQJRXriQ1emLyPSNkuj+9HFGRWM1QydhPhbQMA3 XcJIgPZjHaNLFLG9kQ745EatiTN9nw== =ZiyK -----END PGP SIGNATURE----- --Sig_/4F9etEZHa5OAgo_R2mI+fjA-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 18:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095266607044 (code B ref 45571); Fri, 01 Jan 2021 18:45:02 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 18:44:20 +0000 Received: from localhost ([127.0.0.1]:34842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvPPP-0001pX-Ub for submit@debbugs.gnu.org; Fri, 01 Jan 2021 13:44:20 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:17052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvPPM-0001pN-RY for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 13:44:18 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D6v7d536kz1LBMx; Fri, 1 Jan 2021 19:44:13 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D6v7d536kz1LBMx DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609526653; bh=hAk9266j2IogqDV1Tz0Hf4TDTgSRt0SDDWUJ4hQGm4g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=tOpCG7KU5BIXDk7CnPynBdML+iTuj6sko6nsCn31vBIftXQwaYn+QJyMf07ASe6In 8zW+fldjnIGhKqGAbjiJYwcWgSsGYAninh7GxfrZ52ycQKpwGRzHQ54v18Q3coNYWw ZR8dBz4nV/yrFfuN0yEIiepu5510cTnzpW1puh2I= Message-ID: <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> From: Leo Prikler Date: Fri, 01 Jan 2021 19:44:12 +0100 In-Reply-To: <20210101184838.21869359@scratchpost.org> References: <20210101184838.21869359@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, Am Freitag, den 01.01.2021, 18:50 +0100 schrieb Danny Milosavljevic: > Hello, > > On Fri, 01 Jan 2021 17:20:58 +0100 > Leo Prikler wrote: > > > I don't think changing the way UIDs are allocated by default is a > > good > > solution as that will break many running installations on real > > hardware, that default to those. > > (gnu build accounts), allocate-passwd defaults to keep using the uids > of > existing /etc/passwd entries. So running installations on real > hardware > will not be affected when we change the defaults--otherwise those > installations on real hardware would already have had big problems > regarding > user accounts with the current version of Guix when someone adds a > user account > (system account or not) to them. Then, depending on the order of the > declared > user-accounts, the uids would have swapped. Ah, that puts things into perspective. In other words, the problem is not, that Guix doesn't read /etc/passwd at all, but that it reads the wrong one (the host instead of the guest, so to speak). Should this perhaps be a parameter instead? > > A better solution would be to make > > user accounts and groups explicit configuration wherever account- > > service-type is used, so that it's possible to override them if > > needed. > > They already are explicit. > > For example, (gnu services monitoring) has: > > > (define %darkstat-accounts > > (list (user-account > > (name "darkstat") > > (group "darkstat") > > (system? #t) > > (comment "darkstat daemon user") > > (home-directory "/var/lib/darkstat") > > (shell (file-append shadow "/sbin/nologin"))) > > (user-group > > (name "darkstat") > > (system? #t)))) > > and then > > > (extensions > > (list (service-extension account-service-type > > (const %darkstat-accounts)) > > As you can see, the user and group accounts are already > explicit. What's > more, the uid (and group id) can already be specified right there, > and I > argue that it should be specified right there, and that there should > be a > stable default if it's not specified. How is that explicit? The % even implies, that it's considered internal to the definition. Instead, you'd have (darkstat-accounts config), which default to the current value of %darkstat-accounts, but are configurable at least in the way that they allow you to set their ids. > So to summarize: > > (1) This bug is a real problem, and something should be done about > it. Naturally. > (2) The reason it doesn't currently affect Guix system users is > because there > is logic preferring existing /etc/passwd, /etc/shadow and /etc/group > entries > (which I agree is a good idea). Doesn't help for guix system > container, though. > > Or for NFS network file systems. Any time you have more than one > computer > (even with Guix on it) with a filesystem in the network and regular > users, > you have to have consistent uids or have a lot of weird uid maps per > computer > that someone has to maintain, or worse, an extra service just mapping > them. > Why do that to yourself? In the realm of Guix system, this could be resolved by allowing the user to choose the "seeds" for those files, so to speak (in commands such as init, vm, deploy, etc.), could it not? Especially for (3), carrying over the old shadow from the guest rather than generating a new one with initial passwords sounds like it'd be a necessary precondition for using them with persistent storage. > (3) For /etc/shadow, it also makes sense to keep the existing entry > (the user > name is the key for the search for it btw) because of the password > set. See above. > (4) It makes sense to keep the existing /etc/{passwd,shadow,group} > entries both > for backward compatibility and also for extensibility of guix with > user & group > accounts guix knows nothing about. Not knowing about such accounts sounds somewhat antithetical to Guix, but whatever. > (5) Also for not having this bug with containers, it would still be > better to > just make uid and gid mandatory for "user-account" records. > > (6) Since (5) would move the burden to the user, it would be better > usability > to generate uid and gid in a deterministic manner as a default. Is the current logic non-deterministic in any way other than supporting the reuse of old entries (which you yourself agree is a good thing)? As far as I understand it, same config.scm + same /etc/{passwd,group,shadow} => same /etc/{passwd,group,shadow}. Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 01 Jan 2021 20:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160953257232537 (code B ref 45571); Fri, 01 Jan 2021 20:23:01 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 20:22:52 +0000 Received: from localhost ([127.0.0.1]:34947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvQwl-0008Sj-UM for submit@debbugs.gnu.org; Fri, 01 Jan 2021 15:22:52 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:43924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvQwk-0008SX-0b for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 15:22:50 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 708BE336521B; Fri, 1 Jan 2021 21:22:48 +0100 (CET) Date: Fri, 1 Jan 2021 21:22:42 +0100 From: Danny Milosavljevic Message-ID: <20210101212242.00252cac@scratchpost.org> In-Reply-To: <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> References: <20210101184838.21869359@scratchpost.org> <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/5WUjv37133hjfR1Arb.D_Oq"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/5WUjv37133hjfR1Arb.D_Oq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Leo, On Fri, 01 Jan 2021 19:44:12 +0100 Leo Prikler wrote: > Ah, that puts things into perspective. In other words, the problem is > not, that Guix doesn't read /etc/passwd at all, but that it reads the > wrong one (the host instead of the guest, so to speak). Should this > perhaps be a parameter instead? Considering the goal of Guix, it's weird that with Guix, one needs to store&restore /etc/passwd at all. It's state, but not very useful one. I mean that's how it is right now--but it's still weird. With /etc/shadow maybe there's a slightly better case, but note that the key to find stuff in /etc/shadow can't be the uid--the uid isn't even in there! > How is that explicit? The % even implies, that it's considered > internal to the definition. Explicit means that the user-account record is initialized right there (eve= ry time account-service-type is extended), by a literal. And it is. You can see it plain as day in the guix git repo where account-service-type is used in gnu/services/ . Implicit would be if some code would generate this record on-the-fly, usually leaving stuff hard to change by the maintainer. '(user-account (name "x") ...)' is about as explicit as it gets for a recor= d. The "%" in the name of the binding changes nothing in the literal value. And it indeed is possible to add (uid 4711) in the literal and it will work just fine. > Instead, you'd have (darkstat-accounts > config), which default to the current value of %darkstat-accounts, but > are configurable at least in the way that they allow you to set their > ids. Oh, you want internal service users to be USER-configurable. Indeed that is also what Jason suggested in the initial mail. But I think that that would put undue burden on each user and is really just a workaround. I would really like to caution against us doing a "whack a mole" development approach, where workarounds like that are introduced to work around bugs without understanding the underlying causes. So I disagree that having internal service users be user-configurable is a good idea. > In the realm of Guix system, this could be resolved by allowing the > user to choose the "seeds" for those files, so to speak (in commands > such as init, vm, deploy, etc.), could it not? Sure, but that's a last resort. Better is to eliminate state if possible. > Especially for (3), carrying over the old shadow from the guest rather > than generating a new one with initial passwords sounds like it'd be a > necessary precondition for using them with persistent storage. It depends on what it is used for, really. > > (5) Also for not having this bug with containers, it would still be > > better to > > just make uid and gid mandatory for "user-account" records. > >=20 > > (6) Since (5) would move the burden to the user, it would be better > > usability > > to generate uid and gid in a deterministic manner as a default. =20 > Is the current logic non-deterministic in any way other than supporting > the reuse of old entries (which you yourself agree is a good thing)? It generates uids using a counter, so it depends on what order user-accounts are created in by Guix, which depends on the order the user specifies services in /etc/config.scm and on the order to user accounts are specified in gnu/services/ by guix maintainers. Then the service executable (potentially) goes on to create files using those uids. That means that if you remove or reorder service references in /etc/config.= scm, the uids "want" to change. The only reason they don't change is because the logic prefers the existing /etc/passwd's uids--a stopgap measure at the last second to prevent total chaos. Does any of this sound good to you? I mean, strictly speaking, it's better than the alternative--but that's a l= ow bar. Better would be a making the uid field mandatory and/or generating each uid from the respective name. > As far as I understand it, same config.scm + same > /etc/{passwd,group,shadow} =3D> same /etc/{passwd,group,shadow}. That is the intention of (gnu system shadow), I think. I can't say whether that's the case in practice now or not. It certainly was not the case a few years ago where I did run into the same problem (a necessary condition for the problem to manifest is that the services change--but my /etc/config.scm services forms have been stable for a long time now, and Guix upstream also doesn't change service definitions a lot anymore. So who knows?). --Sig_/5WUjv37133hjfR1Arb.D_Oq Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vhJIACgkQ5xo1VCww uqXjHAgAihpWdLfb4CmXKF0tamt5EkLtW+QXf8gX8vgn74mV6Qj8OwE2G3ZkNsOp xNR994Ri8W2AOdYOGPlxzEr84hCSZtoiseXeIimCayq2uYINkNnSWvvkHTI6+Xce GJ7oMDKtQYFAd6rAMRQ1BtBSpnRg9H9zdtnYryxgsDeQd/U+TceVia3/jLn1XfDP /NuegKSLRwl5QHLIyTk7OMnl+3cXcFCmLx8hbCBus0oq1ufe33nv0K2q5iwKF/js GrBFekj59ALgSDgsUkRekgcXKwIFTr297Jgav2DhiwBGFced64Yrvbn/ToRq3MDj w7gz1qOc2jR2ZBpWIMhqsnvUr0Nkmw== =VfF5 -----END PGP SIGNATURE----- --Sig_/5WUjv37133hjfR1Arb.D_Oq-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts In-Reply-To: Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 00:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160954713722716 (code B ref 45571); Sat, 02 Jan 2021 00:26:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 00:25:37 +0000 Received: from localhost ([127.0.0.1]:35056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvUjg-0005uI-Eu for submit@debbugs.gnu.org; Fri, 01 Jan 2021 19:25:36 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:10623) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvUjd-0005u7-HU for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 19:25:35 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D72jQ4Hfjz1LBSH for <45571@debbugs.gnu.org>; Sat, 2 Jan 2021 01:25:30 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D72jQ4Hfjz1LBSH DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609547130; bh=OuswwNIyfkvYog47WMa/+s/0zHe9GdEvb1HffqzXZjA=; h=Subject:From:Cc:Date:References:From; b=tmH/MZJDrLcklrIWBNOT2SED1a0HKQnI8bMD1QI3fGszJzkYA+7t5Pm4rnFGCXsSA iu5jPpUivwtXXNmLIViaGqBGpdI/Sgv8ZaL8hNiGLizXZNeaODkG+OWZa7lYAgkMg/ qFCGlUB7BJ9r43INUyOL1lcTTuXZ9vaD6XZVqfj4= Message-ID: <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> From: Leo Prikler Date: Sat, 02 Jan 2021 01:25:29 +0100 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> Content-Type: multipart/mixed; boundary="=-I6jPGWIToLDRc+qoSG1n" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --=-I6jPGWIToLDRc+qoSG1n Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Forgot to CC the ML. --=-I6jPGWIToLDRc+qoSG1n Content-Disposition: inline Content-Description: Weitergeleitete Nachricht =?UTF-8?Q?=E2=80=93?= Re: bug#45571: Support stable uids and gids for all accounts Content-Type: message/rfc822 Message-ID: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> Subject: Re: bug#45571: Support stable uids and gids for all accounts From: Leo Prikler To: Danny Milosavljevic Date: Sat, 02 Jan 2021 00:16:45 +0100 In-Reply-To: <20210101212242.00252cac@scratchpost.org> References: <20210101184838.21869359@scratchpost.org> <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> <20210101212242.00252cac@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Danny, Am Freitag, den 01.01.2021, 21:22 +0100 schrieb Danny Milosavljevic: > Hi Leo, >=20 > On Fri, 01 Jan 2021 19:44:12 +0100 > Leo Prikler wrote: >=20 > > Ah, that puts things into perspective. In other words, the problem > > is > > not, that Guix doesn't read /etc/passwd at all, but that it reads > > the > > wrong one (the host instead of the guest, so to speak). Should > > this > > perhaps be a parameter instead? >=20 > Considering the goal of Guix, it's weird that with Guix, one needs to > store&restore /etc/passwd at all. It's state, but not very useful > one. > I mean that's how it is right now--but it's still weird. >=20 > With /etc/shadow maybe there's a slightly better case, but note that > the key > to find stuff in /etc/shadow can't be the uid--the uid isn't even in > there! AFAIU yes, it's state, but not one that Guix can simply do away with.=20 There is not yet a syntax for keeping secrets, which would be needed to fully populate /etc from config.scm. Perhaps we'll get there some day. Also IIUC, account names are supposedly unique, hence my proposed patch to #45570. > > How is that explicit? The % even implies, that it's considered > > internal to the definition. >=20 > Explicit means that the user-account record is initialized right > there (every > time account-service-type is extended), by a literal. >=20 > And it is. You can see it plain as day in the guix git repo where > account-service-type is used in gnu/services/ . >=20 > Implicit would be if some code would generate this > record > on-the-fly, usually leaving stuff hard to change by the maintainer. Fair enough, that's explicit in some sense, but not explicit if we take the config.scm as the point of reference. Since there's no way of explicitly setting it from there without advanced wizardry. > '(user-account (name "x") ...)' is about as explicit as it gets for a > record. >=20 > The "%" in the name of the binding changes nothing in the literal > value. >=20 > And it indeed is possible to add (uid 4711) in the literal and it > will work > just fine. I'm aware you're joking, or at least I hope you are, but I shouldn't have to point out why hardcoding ids into those literals is a bad idea. > > Instead, you'd have (darkstat-accounts > > config), which default to the current value of %darkstat-accounts, > > but > > are configurable at least in the way that they allow you to set > > their > > ids. >=20 > Oh, you want internal service users to be USER-configurable. Indeed > that is > also what Jason suggested in the initial mail. >=20 > But I think that that would put undue burden on each user and is > really just > a workaround. > I would really like to caution against us doing a "whack a mole" > development > approach, where workarounds like that are introduced to work around > bugs > without understanding the underlying causes. So I disagree that > having > internal service users be user-configurable is a good idea. "Undue burden on each user" is a bit exaggerated, considering that the defaults work fine for most. Making them user-configurable would even allow hardcoding a default ID, because users would be able to change that ID if they wanted a different one, eliminating even more reasons to configure them if not for the reason of "because I want to". I also disagree, that this is a problem, that we can solve as Guix System alone. Even if we were to implement your hash idea, other distros would still be keeping their numbering systems. If you share an NFS with a legacy system, you'd still need a mapping or inherit accounts from their settings -- neither of which sound great, but compromises have to be made. In that sense, I agree with Jason that it is a problem, that you can't set service [GU]IDs when you want (or need) to. The question is how to best make them configurable. > > In the realm of Guix system, this could be resolved by allowing the > > user to choose the "seeds" for those files, so to speak (in > > commands > > such as init, vm, deploy, etc.), could it not? >=20 > Sure, but that's a last resort. Better is to eliminate state if > possible. Keyword being "if possible". It is currently not possible to eliminate shadow. > > > (5) Also for not having this bug with containers, it would still > > > be > > > better to > > > just make uid and gid mandatory for "user-account" records. > > >=20 > > > (6) Since (5) would move the burden to the user, it would be > > > better > > > usability > > > to generate uid and gid in a deterministic manner as a default. =20 > > Is the current logic non-deterministic in any way other than > > supporting > > the reuse of old entries (which you yourself agree is a good > > thing)? >=20 > It generates uids using a counter, so it depends on what order > user-accounts are created in by Guix, which depends on the order the > user > specifies services in /etc/config.scm and on the order to user > accounts > are specified in gnu/services/ by guix maintainers. Then the service > executable (potentially) goes on to create files using those uids. >=20 > That means that if you remove or reorder service references in > /etc/config.scm, > the uids "want" to change. The only reason they don't change is > because the > logic prefers the existing /etc/passwd's uids--a stopgap measure at > the last > second to prevent total chaos. >=20 > Does any of this sound good to you? Keeping value judgements aside, it does sound deterministic. Relying on order is also not that big of a deal if you have ways of ensuring order, but you'd also have to ensure, that the expected order is the same as the one actually used, and that's significantly harder to do. An example: You could expect user accounts to be numbered in the order they appear in the field, but you could also expect them to be numbered in reverse order (because services can add accounts and they're usually consed). In that sense, yeah, relying on order is certainly not optimal. > I mean, strictly speaking, it's better than the alternative--but > that's a low > bar. >=20 > Better would be a making the uid field mandatory and/or generating > each uid > from the respective name. Statistically speaking hashes collide sooner than incrementing numbers do. Granted, they might work as mitigation, but they're no solution on their own either. > > As far as I understand it, same config.scm + same > > /etc/{passwd,group,shadow} =3D> same /etc/{passwd,group,shadow}. >=20 > That is the intention of (gnu system shadow), I think. You mean (gnu build accounts), right? > I can't say whether that's the case in practice now or not. It > certainly was not the case a few > years ago where I did run into the same problem (a necessary > condition for > the problem to manifest is that the services change--but my > /etc/config.scm > services forms have been stable for a long time now, and Guix > upstream also > doesn't change service definitions a lot anymore. So who knows?). Well, the point here was not to state how outputs differ when the inputs differ, but what happens, when they stay the same. I have another machine, that I carried over from a Gentoo install using different user names, and there I have a different UID from this machine, where I did a clean install (and it has stayed the same UID since). IOW this appears to be functioning as intended. Regards, Leo --=-I6jPGWIToLDRc+qoSG1n-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts References: In-Reply-To: Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 01:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160955102728986 (code B ref 45571); Sat, 02 Jan 2021 01:31:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 01:30:27 +0000 Received: from localhost ([127.0.0.1]:35077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvVkQ-0007XS-Ia for submit@debbugs.gnu.org; Fri, 01 Jan 2021 20:30:26 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:33578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvVkO-0007XJ-Mj for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 20:30:25 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id CFCB43361792 for <45571@debbugs.gnu.org>; Sat, 2 Jan 2021 02:30:23 +0100 (CET) Date: Sat, 2 Jan 2021 02:30:20 +0100 From: Danny Milosavljevic Message-ID: <20210102023020.3e4186d3@scratchpost.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/PloWeE1bPcQuOL_bhLkyAOK"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/PloWeE1bPcQuOL_bhLkyAOK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Leo, On Fri, 01 Jan 2021 19:44:12 +0100 Leo Prikler wrote: > Ah, that puts things into perspective. In other words, the problem is > not, that Guix doesn't read /etc/passwd at all, but that it reads the > wrong one (the host instead of the guest, so to speak). Should this > perhaps be a parameter instead? =20 Considering the goal of Guix, it's weird that with Guix, one needs to store&restore /etc/passwd at all. It's state, but not very useful one. I mean that's how it is right now--but it's still weird. With /etc/shadow maybe there's a slightly better case, but note that the key to find stuff in /etc/shadow can't be the uid--the uid isn't even in there! > How is that explicit? The % even implies, that it's considered > internal to the definition. =20 Explicit means that the user-account record is initialized right there (eve= ry time account-service-type is extended), by a literal. And it is. You can see it plain as day in the guix git repo where account-service-type is used in gnu/services/ . Implicit would be if some code would generate this record on-the-fly, usually leaving stuff hard to change by the maintainer. '(user-account (name "x") ...)' is about as explicit as it gets for a recor= d. The "%" in the name of the binding changes nothing in the literal value. And it indeed is possible to add (uid 4711) in the literal and it will work just fine. > Instead, you'd have (darkstat-accounts > config), which default to the current value of %darkstat-accounts, but > are configurable at least in the way that they allow you to set their > ids. =20 Oh, you want internal service users to be USER-configurable. Indeed that is also what Jason suggested in the initial mail. But I think that that would put undue burden on each user and is really just a workaround. I would really like to caution against us doing a "whack a mole" development approach, where workarounds like that are introduced to work around bugs without understanding the underlying causes. So I disagree that having internal service users be user-configurable is a good idea. > In the realm of Guix system, this could be resolved by allowing the > user to choose the "seeds" for those files, so to speak (in commands > such as init, vm, deploy, etc.), could it not? =20 Sure, but that's a last resort. Better is to eliminate state if possible. > Especially for (3), carrying over the old shadow from the guest rather > than generating a new one with initial passwords sounds like it'd be a > necessary precondition for using them with persistent storage. =20 It depends on what it is used for, really. > > (5) Also for not having this bug with containers, it would still be > > better to > > just make uid and gid mandatory for "user-account" records. > >=20 > > (6) Since (5) would move the burden to the user, it would be better > > usability > > to generate uid and gid in a deterministic manner as a default. =20 > Is the current logic non-deterministic in any way other than supporting > the reuse of old entries (which you yourself agree is a good thing)? =20 It generates uids using a counter, so it depends on what order user-accounts are created in by Guix, which depends on the order the user specifies services in /etc/config.scm and on the order to user accounts are specified in gnu/services/ by guix maintainers. Then the service executable (potentially) goes on to create files using those uids. That means that if you remove or reorder service references in /etc/config.= scm, the uids "want" to change. The only reason they don't change is because the logic prefers the existing /etc/passwd's uids--a stopgap measure at the last second to prevent total chaos. Does any of this sound good to you? I mean, strictly speaking, it's better than the alternative--but that's a l= ow bar. Better would be a making the uid field mandatory and/or generating each uid from the respective name. > As far as I understand it, same config.scm + same > /etc/{passwd,group,shadow} =3D> same /etc/{passwd,group,shadow}. =20 That is the intention of (gnu system shadow), I think. I can't say whether that's the case in practice now or not. It certainly was not the case a few years ago where I did run into the same problem (a necessary condition for the problem to manifest is that the services change--but my /etc/config.scm services forms have been stable for a long time now, and Guix upstream also doesn't change service definitions a lot anymore. So who knows?). --=20 W: https://www.friendly-machines.at/ --Sig_/PloWeE1bPcQuOL_bhLkyAOK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vzK0ACgkQ5xo1VCww uqU9ZAgAo6m6zX2woiXZJdWfwSQ60B43JfyXRGuh16kI4fKcfAYCfgKjgs/Znr/M EWjRMqHZjVAAfyHog9bBOMicqMG2y6K1zAWNnGgDaSWOiOdmq+A1Doy1K8qrr+GA /C0wsqSh/WCA4+gPlJozM4m7GLy2L7KMeBZwlGL2jsQOWuR+cfAO+6UrJ1NzvWrq weArWrj6q9cCO0D47yXs1rTSSJY3Q5X2q6VeTK3hcyvnMsnuOvRe0sddDMMU7Ok0 GLiUXQoXGwwuYNm712Gso2/+ZcicYs2x3GGPWaKFv2qYIFB4ImX4Zw96iLuQos7k C8oT0ppHH/Y/N4fiicBQyB6hIcvbnQ== =b+TB -----END PGP SIGNATURE----- --Sig_/PloWeE1bPcQuOL_bhLkyAOK-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 01:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160955166029876 (code B ref 45571); Sat, 02 Jan 2021 01:41:01 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 01:41:00 +0000 Received: from localhost ([127.0.0.1]:35082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvVud-0007lo-Oz for submit@debbugs.gnu.org; Fri, 01 Jan 2021 20:40:59 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:34162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvVub-0007lf-B6 for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 20:40:58 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 61CD133609D6; Sat, 2 Jan 2021 02:40:56 +0100 (CET) Date: Sat, 2 Jan 2021 02:40:54 +0100 From: Danny Milosavljevic Message-ID: <20210102024054.158bb3ba@scratchpost.org> In-Reply-To: <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/.3wCljM+PBkrfyvcyd/Aa46"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/.3wCljM+PBkrfyvcyd/Aa46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Leo, On Sat, 02 Jan 2021 00:16:45 +0100 Leo Prikler wrote: > > And it indeed is possible to add (uid 4711) in the literal and it > > will work > > just fine. =20 > I'm aware you're joking, or at least I hope you are,=20 What? It's perfectly reasonable for a distribution to have stable system user ids. That's what Debian supports, too: https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes >0-99: >Globally allocated by the Debian project, the same on every Debian system.= These ids will appear in the passwd and group files of all Debian systems,= new ids in this range being added automatically as the base-passwd package= is updated. >Packages which need a single statically allocated uid or gid should use on= e of these; their maintainers should ask the base-passwd maintainer for ids. [...] >60000-64999: >Globally allocated by the Debian project, but only created on demand. The = ids are allocated centrally and statically, but the actual accounts are onl= y >created on users=E2=80=99 systems on demand. >[...] And so does FreeBSD, see https://www.freebsd.org/doc/en/books/porters-handbook/users-and-groups.= html and https://github.com/freebsd/freebsd-ports/blob/master/UIDs for the actua= l registry. For that matter, IANA does this for ports and many other things. And so on. Stable defaults are *good*. Right now, the Guix service user user-account record specifies 99% of the /etc/passwd entry. I indeed propose to make it 100% for system users for G= uix system services. >but I shouldn't have to point out why hardcoding ids into those literals i= s a >bad idea. You have to point that out to us--especially since Guix service user accoun= ts of the account-service-type extension can only be instantiated once anyway. --Sig_/.3wCljM+PBkrfyvcyd/Aa46 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vzyYACgkQ5xo1VCww uqUbsAgAjLphtZlJJ10DEg8c6typg0Rq5EWdyRhaMoSFRDfCO2wXX9vOdAQBiN23 /8bjCJ9Lh5so8E3jrY1xjCKtrkI+oNL9JjhJ/1rBwPCeq9EX2k73uzaXmWndDbE1 vMo7rwrKDxde6DsOAivgLdHWRnxwOxbOK+2IMNjWqPX7rJiPGpNntVTbZauZCTB4 CTkoHbHIdwws8VPIhfoRH1nT5kb6jVQHcjOjuB57lkhhzmb33RCXvS/yGbuazxSH m1VGWYN5mJAg0TFMWR4K1AANHASECnF7k0jKGGB21WV+JgFKwpspCdvcv77IHMB4 RE7k53vfolCQ/VQ/g+78BbA8LB8gUw== =6948 -----END PGP SIGNATURE----- --Sig_/.3wCljM+PBkrfyvcyd/Aa46-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 03:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095570135491 (code B ref 45571); Sat, 02 Jan 2021 03:11:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 03:10:13 +0000 Received: from localhost ([127.0.0.1]:35121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvXIy-0001QU-LE for submit@debbugs.gnu.org; Fri, 01 Jan 2021 22:10:12 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:10418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvXIw-0001QK-OX for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 22:10:12 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D76ML6zfvz1LLyb; Sat, 2 Jan 2021 04:10:06 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D76ML6zfvz1LLyb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609557007; bh=J46b67v6PnzqjnuGfGVgELC1UnJPdSugWPWgunatRsw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UsA2P3FlNUNGZCHDB5byE99bczsqfY9UUTCYKfg1oDRILFpTuRzcCKMVKvHpxPcOV CKn2Se7PpNSAJlMwcgX54CnfEo/fnsyAtxD6ioAWImQlciKWYAAx1g2NMGYAimS2kV NzoroWXWebC7KA/hQ5yYTobJ9r4ny9GENHkdfBEg= Message-ID: <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> From: Leo Prikler Date: Sat, 02 Jan 2021 04:10:06 +0100 In-Reply-To: <20210102024054.158bb3ba@scratchpost.org> References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Danny, Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny Milosavljevic: > Hi Leo, > > On Sat, 02 Jan 2021 00:16:45 +0100 > Leo Prikler wrote: > > > > And it indeed is possible to add (uid 4711) in the literal and it > > > will work > > > just fine. > > I'm aware you're joking, or at least I hope you are, > > What? It's perfectly reasonable for a distribution to have stable > system > user ids. > > That's what Debian supports, too: > > https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes > > > 0-99: > > Globally allocated by the Debian project, the same on every Debian > > system. These ids will appear in the passwd and group files of all > > Debian systems, new ids in this range being added automatically as > > the base-passwd package is updated. > > Packages which need a single statically allocated uid or gid should > > use one of these; their maintainers should ask the base-passwd > > maintainer for ids. > > [...] > > > 60000-64999: > > Globally allocated by the Debian project, but only created on > > demand. The ids are allocated centrally and statically, but the > > actual accounts are only >created on users’ systems on demand. > > [...] You do know, that services such as gdm, pulseaudio, avahi, sshd, mpd, and others fall into neither region, do you? > And so does FreeBSD, > see > https://www.freebsd.org/doc/en/books/porters-handbook/users-and-groups.html > and https://github.com/freebsd/freebsd-ports/blob/master/UIDs for the > actual registry. If I had a guixbuilder for every account in that list, that I didn't need, I'd have a lot of guixbuilders. Probably more than I could allocate into a contiguous block under FreeBSD. > For that matter, IANA does this for ports and many other things. And > so on. > > Stable defaults are *good*. So is leaving room for other configurations. Some of the bindings we now consider "default" were only made because other ports were already claimed. Not to mention overlaps, such as port 465. > Right now, the Guix service user user-account record specifies 99% of > the > /etc/passwd entry. I indeed propose to make it 100% for system users > for Guix > system services. What's the remaining 1%? > > but I shouldn't have to point out why hardcoding ids into those > > literals is a > > bad idea. > > You have to point that out to us--especially since Guix service user > accounts > of the account-service-type extension can only be instantiated once > anyway. Unlike in other systems, where you'd expect people to manually fiddle around with such files and tragically fail, in Guix your OS config.scm should reflect the actual state of the system (modulo secrets, that can't be expressed currently). If you claim UID 92 for GDM like FreeBSD does, but people live on installations, that have the old default of 983 (or any other, depending on the number of guixbuilders you have), that's going to cause problems. Perhaps not the same problems that led to the creation of its activation-service, but still. That's not to say, that claiming such IDs is *always* bad, just that it's bad to do so without leaving room for configuration. I should likely have worded that better, but at the same time there was context from which one could have inferred, that I meant hardcoding IDs into unchanging constants. >From the solutions we do have so far, I believe that making user accounts an explicit part of service configuration (in what shape may still be up for debate), with reasonable defaults including numeric UIDs and GIDs (at least) for essential services such as GDM sounds like the best option. WDYT? Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 14:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Cc: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160959655828409 (code B ref 45571); Sat, 02 Jan 2021 14:10:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 14:09:18 +0000 Received: from localhost ([127.0.0.1]:58958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvhan-0007O6-Q0 for submit@debbugs.gnu.org; Sat, 02 Jan 2021 09:09:18 -0500 Received: from mail-ed1-f51.google.com ([209.85.208.51]:43698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvhal-0007Ne-Al for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 09:09:16 -0500 Received: by mail-ed1-f51.google.com with SMTP id y24so22214950edt.10 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 06:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=625isnM4ljgWeHv3hSqIywHam0mk+OMf03WXeB5W/8U=; b=XB9BQHk7VljRSHYhgaa62AqAtmVWOJR14FrQYv/PCB74FZt5DnN5Nf1g+RjihNuuNk bqUbzOIOhN2+kDtThtttSJ6pBfpxBRHt8K7fnl5nqJ+OXwwZmqd2HFCrqp9869NhXAJM fhczrIX4jFj1bx+hZe7INQg2Bbr0ID6GRTARrK0bVBbBzuF6OwsyPUQ5dnW/Mx4o4XrX 3JIlTu/me2CHr6GImjo5xg1wWAr4cOYorQRj4wGCIiSkwyGGl5rOWfAvxyNd4cVF1t4C IwJAQQ4z9WlHDDTYDNIId4XLyHh20vjxAg5AQyr0TBXj89mt1ZQDbwc5JdFpCsJDjd8B DcUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=625isnM4ljgWeHv3hSqIywHam0mk+OMf03WXeB5W/8U=; b=Mq+YmsodxjzaSxCWRj9seSYotM/+LRLsWO4GP7ak8qRwMPIbHZJi0Q2+bLf77rg1o3 hqmszQGr9sfrd14m1eG+sfv6SN8fSvK8z9HWRLTomMxKsf6J7qlVrl2FMS6TJ3m97J0y NOBoNlridG3O1CNfJyhOhUpum/UNlww1UiobFJKDGh0JuTbb3Bm0iE4enFLCpGYV58U9 51ENik0/a6+T9Fhx9y4NsW67TY4R9n0adKiYaiZYU92PwzZb6YhhjKQBN+rhm2VwuwpZ sib8mfiJaWtBawX+ho3Ifh+hL4jMqmzMS3/9IIZd//vqAI5EOU5lPh/Q225Urw71qOr1 yvkw== X-Gm-Message-State: AOAM533dQWi3bKs4PM1+/gmtq3+wwTUp550b2k7YZBtqfdwBfGS0Mwq6 4DsjWj6Ilf6hMLJ4HcK0RGBa4Q3/RJSFeTuR8czQhRGl X-Google-Smtp-Source: ABdhPJyfQJbxB8+EWk+p2a2m4SuHmiGmQ3R5NNiQatIYsrJXoMJi+bRp9+Nm/us3vgrhwHdL94iw0ERsT+xnTGNZASw= X-Received: by 2002:aa7:d916:: with SMTP id a22mr63043757edr.122.1609596174358; Sat, 02 Jan 2021 06:02:54 -0800 (PST) MIME-Version: 1.0 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> In-Reply-To: <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> From: Jason Conroy Date: Sat, 2 Jan 2021 09:02:18 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000345b2805b7eb50e5" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000345b2805b7eb50e5 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler wrote: > Hi Danny, > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny Milosavljevic: > > Hi Leo, > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > Leo Prikler wrote: > > > > > > And it indeed is possible to add (uid 4711) in the literal and it > > > > will work > > > > just fine. > > > I'm aware you're joking, or at least I hope you are, > > > > What? It's perfectly reasonable for a distribution to have stable > > system > > user ids. > My reaction to this was not that defaults are bad, but that dispersing numeric literals throughout the code is. Collectively these values specify the contents of a registry, so that registry might as well be located centrally. Or at least, there should be some mechanism to ensure that two services can't claim the same default ID, otherwise the collision will not manifest until somebody instantiates a system with the colliding services. >From the solutions we do have so far, I believe that making user > accounts an explicit part of service configuration (in what shape may > still be up for debate), with reasonable defaults including numeric > UIDs and GIDs (at least) for essential services such as GDM sounds like > the best option. WDYT? > > Regards, > Leo > That seems reasonable to me. As for representation, I think there's value decoupling these settings from a service's own config so that support for custom UIDs/GIDs remains consistent across services. --000000000000345b2805b7eb50e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 1, 2021 at 10:11 PM Leo P= rikler <leo.prikler@stu= dent.tugraz.at> wrote:
Hi Danny,
Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny Milosavljevic:
> Hi Leo,
>
> On Sat, 02 Jan 2021 00:16:45 +0100
> Leo Prikler <leo.prikler@student.tugraz.at> wrote:
>
> > > And it indeed is possible to add (uid 4711) in the literal a= nd it
> > > will work
> > > just fine.=C2=A0
> > I'm aware you're joking, or at least I hope you are,
>
> What?=C2=A0 It's perfectly reasonable for a distribution to have s= table
> system
> user ids.

My reaction to this was not t= hat defaults are bad, but that dispersing numeric literals throughout the c= ode is. Collectively these values specify the contents of a registry, so th= at registry might as well be located centrally. Or at least, there should b= e some mechanism to ensure that two services can't claim the same defau= lt ID, otherwise the collision will not manifest until somebody instantiate= s a system with the colliding services.

>From the solutions we do have so far, I believe that making user
accounts an explicit part of service configuration (in what shape may
still be up for debate), with reasonable defaults including numeric
UIDs and GIDs (at least) for essential services such as GDM sounds like
the best option.=C2=A0 WDYT?

Regards,
Leo

That seems reasonable to me. As for= representation, I think there's value decoupling these settings from a= service's own config so that support for custom UIDs/GIDs remains cons= istent across services.
--000000000000345b2805b7eb50e5-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 14:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Jason Conroy Cc: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.1609597768372 (code B ref 45571); Sat, 02 Jan 2021 14:30:03 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 14:29:28 +0000 Received: from localhost ([127.0.0.1]:59539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvhuJ-00005w-SI for submit@debbugs.gnu.org; Sat, 02 Jan 2021 09:29:28 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:15087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvhuG-00005f-U6 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 09:29:26 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D7PR50pFpz3wb6; Sat, 2 Jan 2021 15:29:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609597761; bh=NoQKFtg4ivLRT95E5rJuZ9HLWDXBHi/u5Av446SAVxc=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=KLQNRN035dHhwXm7ETgpU1r5VBVjtuDiGkbN19DXwZaLT7mxPf25aBLGhqoDX6HtG VQ1P5loj1Ucoju6ILJoLSSpPEWW/r+jSQcgxQ5QHey+ONKm41MjBr55Vj8WpETZgIH xTqavA9vFnc6W7KzANpOgC94Pra8cJ5XPRFsM358= Message-ID: <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> From: Leo Prikler Date: Sat, 02 Jan 2021 15:29:20 +0100 In-Reply-To: References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Jason, Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy: > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler < > leo.prikler@student.tugraz.at> wrote: > > Hi Danny, > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > Milosavljevic: > > > Hi Leo, > > > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > > Leo Prikler wrote: > > > > > > > > And it indeed is possible to add (uid 4711) in the literal > > and it > > > > > will work > > > > > just fine. > > > > I'm aware you're joking, or at least I hope you are, > > > > > > What? It's perfectly reasonable for a distribution to have > > stable > > > system > > > user ids. > > My reaction to this was not that defaults are bad, but that > dispersing numeric literals throughout the code is. Collectively > these values specify the contents of a registry, so that registry > might as well be located centrally. Or at least, there should be some > mechanism to ensure that two services can't claim the same default > ID, otherwise the collision will not manifest until somebody > instantiates a system with the colliding services. I think it would suffice to raise a condition from shadow.scm, much like my proposed fix for #45570. As far as development is concerned, one could add a check to see, that no conflicts exist between services extending account-service-type. > > From the solutions we do have so far, I believe that making user > > accounts an explicit part of service configuration (in what shape > > may > > still be up for debate), with reasonable defaults including numeric > > UIDs and GIDs (at least) for essential services such as GDM sounds > > like > > the best option. WDYT? > > > > Regards, > > Leo > > That seems reasonable to me. As for representation, I think there's > value decoupling these settings from a service's own config so that > support for custom UIDs/GIDs remains consistent across services. In this case I'd agree with Danny, that asking users to update two fields to get one service working puts an excessive burden on them. To be fair, I don't even necessarily think, that making the full account configurable is a good idea, unless someone wants to argue, that there's value in potentially giving those accounts shell access. At the very least, there should be syntax like (user-account (inherit sane-system-account-defaults) (name "gdm") (id 92)) Perhaps there could also be a procedure (system-account+group name #:key comment uid gid). Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 14:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Jason Conroy Cc: 45571@debbugs.gnu.org, Leo Prikler Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095990262488 (code B ref 45571); Sat, 02 Jan 2021 14:51:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 14:50:26 +0000 Received: from localhost ([127.0.0.1]:59595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviEc-0000e3-1B for submit@debbugs.gnu.org; Sat, 02 Jan 2021 09:50:26 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:51766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviEX-0000dr-Te for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 09:50:24 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 23EE833629A1; Sat, 2 Jan 2021 15:50:20 +0100 (CET) Date: Sat, 2 Jan 2021 15:50:02 +0100 From: Danny Milosavljevic Message-ID: <20210102155002.2360e505@scratchpost.org> In-Reply-To: References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/yB4v14KWS4TPRUmeGq.gufc"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/yB4v14KWS4TPRUmeGq.gufc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jason, On Sat, 2 Jan 2021 09:02:18 -0500 Jason Conroy wrote: > My reaction to this was not that defaults are bad, but that dispersing > numeric literals throughout the code is.=20 In general that is not exactly true. What you want is some way to check the uids for collisions--and putting them into one file only and manually checking is only one way to do that. And it's not ideal because then the u= id to use for an account would be in some random file far away from the actual point of use. If you mean having both the central registry, and the numeric literal throughout the code, carry on--I agree. We also disperse shepherd service names and many other similar things across literals in the source code of Guix. Those can cause similar problems. I agree that it would be better to have a checker, and central registry, for cross-checking--but right now we don't do that for a lot of other things, among which are the shepherd service names, dbus service names and dbus interface names. This is guile--it could find and lint user account definitions perfectly we= ll, no matter where they are. There could be an automated check that the uids = are not duplicated, at compile or lint time. It would be nice to have such a checker for the dbus things, too. But seriously, at this point I don't think any of this in the currently-discussed form adds enough value to be worth the complexity and the risk of changing it in the first place. >Collectively these values specify > the contents of a registry, so that registry might as well be located > centrally.=20 I agree, if in addition. (Or if a registry is undesireable, calculate the uids by user name. These are the possibilities. If hashing user names is too uncommon on UNIX elsewhere, I say that we have no /usr or /lib, so we are not exactly d= oing common things in Guix because they are common--what we do really depends on= the merits) >Or at least, there should be some mechanism to ensure that two > services can't claim the same default ID, otherwise the collision will not > manifest until somebody instantiates a system with the colliding services. I agree--that mechanism would need to be added. > >From the solutions we do have so far, I believe that making user > > accounts an explicit part of service configuration (in what shape may > > still be up for debate),=20 Not everything needs to be user configurable. You suggest having these kin= ds of things especially user-configurable as a work-around for them not being stable, right? Or do you want it in general? I would like to avoid them here, if only needed for that reason. (Also, if they are user-configurable, then it's much easier for uid collisi= ons to happen than if Guix manages them) So after thinking about it some more, I disagree that that is the best opti= on for this specific problem. In my opinion, the best option here is all of these things: (1) To document that you need to seed /etc/passwd (for Docker etc) (2) For guix system container to default to the host's /etc/passwd and (3) For guix system container to add and retain (!) its own /etc/passwd for accounts only it has (merged together with the host's /etc/passwd for ease of implementation) The suggestions I made before that would obsolete /etc/passwd storage got watered down to a version where they don't obsolete /etc/passwd storage and thus I oppose doing them in that form. It would be making the stuff more complicated--and now you'd have TWO /etc/passwd: * one /etc/template-passwd (for the uid registry) (might as well integrate that into guix as a scheme file, though), * and one /etc/passwd with the currently created users.=20 This seems to be excessive just for making uids stable. > That seems reasonable to me. As for representation, I think there's value > decoupling these settings from a service's own config so that support for > custom UIDs/GIDs remains consistent across services. Is there a need for using custom service UIDs? I think if so, that is independent of this bug report, which asked for stable UIDs and GIDs. --Sig_/yB4v14KWS4TPRUmeGq.gufc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/wiBoACgkQ5xo1VCww uqWENQf+I93c+mzIWTXh79ee4vIqnSYmnjLzr2GVA57Odi4jmJYUte7Xg3Tvsi8f 8FkVjN4MWg7Bu6vbLinJlH//DJrxJ09I/0rdU2EGtHbVTMn4XPcj/PByJOyFkyTc z7FRXidaOUOZALDKU/2ZWjP38EukUvrBGfMbr7AqHdK80tAeCCFcDt8G73y/GJkP Hc7oLwbAfYKuqEOwavcuuvzhlfmd94W/pZCNgATZjMwNKJ+J5hy8RxA7Ot0yXlcO deRzX0PGebi/uSEweL+SkETnsl3S9jlSwMaukWqwA8KLVa1vUzIKbNXhZZC/qSgq Nh1gJEeZpvVc8fs7pjMI321/TWK1OA== =2IDa -----END PGP SIGNATURE----- --Sig_/yB4v14KWS4TPRUmeGq.gufc-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Cc: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095992242809 (code B ref 45571); Sat, 02 Jan 2021 14:54:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 14:53:44 +0000 Received: from localhost ([127.0.0.1]:59603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviHo-0000jE-0s for submit@debbugs.gnu.org; Sat, 02 Jan 2021 09:53:44 -0500 Received: from mail-ej1-f41.google.com ([209.85.218.41]:39318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviHm-0000j0-07 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 09:53:42 -0500 Received: by mail-ej1-f41.google.com with SMTP id n26so30628760eju.6 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 06:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b4adf6M3zDTcn0DAwdtgvyyy8h0dqBbol3TyFcqOC4E=; b=L6mCX8VuJRi0KS+KSlpyoWQwlU+KJqlwehp9Q4SoJASgxOe4sVs1nnihbhJCX0RBbW jxnxuN4RUUx/FEQvfkSfRKm7Ab8n5Z9wMZTMExZ+MZqerLJLjGMATCeotvicN8Pc9uDZ ij7NJODKVvMB3H4lYeE5gRqTJrSlZMztKrBni5J/ZVp4oIJJEBHqVj/zrnVCgJW6MLrK Jk9wF7T3WXjE5O4jydU+VikqMeDW3dVJmhecMgMeUeDDtlwwV3KHh4kWeF2UVHlx/S7o u+E27nQvESZEtvXWvkQosClb6L6Tm5YNWyzq3J+iP3eS2zvR2WaEWYiRNwPI88NBakze RhVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b4adf6M3zDTcn0DAwdtgvyyy8h0dqBbol3TyFcqOC4E=; b=tmhr5l0Jwqkj2jybmPZfXhTrdnMA5sWZuUOtDb1RkLaPy5aMg89+1+bnbRR1qDSdtC V+pbt9sSptjJeDg0p71ZPn2Q1bTMvvq/moaDPZGe2i4cxyo7/Dc3ytEGaJPi5vz+Slsh 35QpCQaCgqNZtZy3mtV3nss9OK4unBE5nYN8SKW/XkvHdr37kPxqMws53qdX5HpQvhhB gC8SISd4YBhPHUe8gnpuWiHH9DN50XpwY9SDqOnFHBUH6GjWFzU62AP7JzclnMKZL2vy BmnfjvQGcmIze8k/TRZDnjJiAeM1jdgjCx/2zStGVqC7xQ+6nY77uSpauaC6B4UEutVF jdow== X-Gm-Message-State: AOAM531JfX+k/Q5fFySg8uvUqH3OulVK95GadLruK2/tNi4KytddaAWX A/PNVh8W36YqRihZcw8+q+UTQVVUT0JFbv1zLU4= X-Google-Smtp-Source: ABdhPJy8P4aQ9GyGMpC2a9yfjIchD6j3Xc74OHlqMsgGcnFfKeyWDQPFc/sG+Je3qq0GW1Alaaw/YC8UKW4KbaCUKcA= X-Received: by 2002:a17:906:2f83:: with SMTP id w3mr8733371eji.292.1609599216085; Sat, 02 Jan 2021 06:53:36 -0800 (PST) MIME-Version: 1.0 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> In-Reply-To: <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> From: Jason Conroy Date: Sat, 2 Jan 2021 09:52:59 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000816e2f05b7ec05d9" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000816e2f05b7ec05d9 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler wrote: > Hi Jason, > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy: > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler < > > leo.prikler@student.tugraz.at> wrote: > > > Hi Danny, > > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > > Milosavljevic: > > > > Hi Leo, > > > > > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > > > Leo Prikler wrote: > > > > > > > > > > And it indeed is possible to add (uid 4711) in the literal > > > and it > > > > > > will work > > > > > > just fine. > > > > > I'm aware you're joking, or at least I hope you are, > > > > > > > > What? It's perfectly reasonable for a distribution to have > > > stable > > > > system > > > > user ids. > > > > My reaction to this was not that defaults are bad, but that > > dispersing numeric literals throughout the code is. Collectively > > these values specify the contents of a registry, so that registry > > might as well be located centrally. Or at least, there should be some > > mechanism to ensure that two services can't claim the same default > > ID, otherwise the collision will not manifest until somebody > > instantiates a system with the colliding services. > I think it would suffice to raise a condition from shadow.scm, much > like my proposed fix for #45570. As far as development is concerned, > one could add a check to see, that no conflicts exist between services > extending account-service-type. > Assuming that authors of new services tend to choose the lowest free ID, is this validation sufficient to ensure that two services checked around the same time by different authors won't collide? > > > > From the solutions we do have so far, I believe that making user > > > accounts an explicit part of service configuration (in what shape > > > may > > > still be up for debate), with reasonable defaults including numeric > > > UIDs and GIDs (at least) for essential services such as GDM sounds > > > like > > > the best option. WDYT? > > > > > > Regards, > > > Leo > > > > That seems reasonable to me. As for representation, I think there's > > value decoupling these settings from a service's own config so that > > support for custom UIDs/GIDs remains consistent across services. > In this case I'd agree with Danny, that asking users to update two > fields to get one service working puts an excessive burden on them. Leo, I'm not sure what you mean by updating two fields. Are you saying that some services already permit manual selection of UIDs? I was proposing setting that value in the "users" section of operating-system (or elsewhere) rather than setting it in the "services" section, but not both places. Since Guix already uses a central allocator for UIDs and GIDs (implemented using simple counters), I was imagining a model where the decision is still made centrally, but with different inputs: 1) a global mapping from user/group name to default ID; and 2) a similar name-to-ID mapping in operating-system where users specify their overrides. > > To > be fair, I don't even necessarily think, that making the full account > configurable is a good idea, unless someone wants to argue, that > there's value in potentially giving those accounts shell access. The thought of making other parts of the account configurable occurred to me, but I couldn't come up with any serious use cases either. > At > the very least, there should be syntax like > > (user-account > (inherit sane-system-account-defaults) > (name "gdm") > (id 92)) > > Perhaps there could also be a procedure (system-account+group name > #:key comment uid gid). > > Regards, > Leo > > --000000000000816e2f05b7ec05d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 2, 2021 at 9:29 AM Leo Pr= ikler <leo.prikler@stud= ent.tugraz.at> wrote:
Hi Jason,
Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy:
> On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler <
> leo= .prikler@student.tugraz.at> wrote:
> > Hi Danny,
> > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny
> > Milosavljevic:
> > > Hi Leo,
> > >
> > > On Sat, 02 Jan 2021 00:16:45 +0100
> > > Leo Prikler <leo.prikler@student.tugraz.at> wrote:
> > >
> > > > > And it indeed is possible to add (uid 4711) in the= literal
> > and it
> > > > > will work
> > > > > just fine.=C2=A0
> > > > I'm aware you're joking, or at least I hope you= are,
> > >
> > > What?=C2=A0 It's perfectly reasonable for a distribution= to have
> > stable
> > > system
> > > user ids.
>
> My reaction to this was not that defaults are bad, but that
> dispersing numeric literals throughout the code is. Collectively
> these values specify the contents of a registry, so that registry
> might as well be located centrally. Or at least, there should be some<= br> > mechanism to ensure that two services can't claim the same default=
> ID, otherwise the collision will not manifest until somebody
> instantiates a system with the colliding services.
I think it would suffice to raise a condition from shadow.scm, much
like my proposed fix for #45570.=C2=A0 As far as development is concerned,<= br> one could add a check to see, that no conflicts exist between services
extending account-service-type.

Assuming tha= t authors of new services tend to choose the lowest free ID, is this valida= tion sufficient to ensure that two services checked around the same time by= different authors won't collide?
= =C2=A0
> > From the solutions we do have so far, I believe that making user<= br> > > accounts an explicit part of service configuration (in what shape=
> > may
> > still be up for debate), with reasonable defaults including numer= ic
> > UIDs and GIDs (at least) for essential services such as GDM sound= s
> > like
> > the best option.=C2=A0 WDYT?
> >
> > Regards,
> > Leo
>
> That seems reasonable to me. As for representation, I think there'= s
> value decoupling these settings from a service's own config so tha= t
> support for custom UIDs/GIDs remains consistent across services.
<= /blockquote>
In this case I'd agree with Danny, that asking users to update two
fields to get one service working puts an excessive burden on them.=C2=A0 <= /blockquote>

Leo, I'm not sure what you mean by updating = two fields. Are you saying that some services already permit manual selecti= on of UIDs? I was proposing setting that value in the "users" sec= tion of operating-system (or elsewhere) rather than setting it in the "= ;services" section, but not both places.

Since Guix already uses a central a= llocator for UIDs and GIDs (implemented using simple counters), I was imagi= ning a model where the decision is still made centrally, but with different= inputs: 1) a global mapping from user/group name to default ID; and 2) a s= imilar name-to-ID mapping in operating-system where users specify their ove= rrides.
=C2=A0
To
be fair, I don't even necessarily think, that making the full account configurable is a good idea, unless someone wants to argue, that
there's value in potentially giving those accounts shell access.=C2=A0 =

The thought of making other parts of the a= ccount configurable occurred to me, but I couldn't come up with any ser= ious use cases either.
=C2=A0
At
the very least, there should be syntax like

(user-account
=C2=A0(inherit sane-system-account-defaults)
=C2=A0(name "gdm")
=C2=A0(id 92))

Perhaps there could also be a procedure (system-account+group name
#:key comment uid gid).

Regards,
Leo

--000000000000816e2f05b7ec05d9-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 15:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095998604554 (code B ref 45571); Sat, 02 Jan 2021 15:05:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:04:20 +0000 Received: from localhost ([127.0.0.1]:60387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviS4-0001BO-CL for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:04:20 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:52548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviS3-0001BG-6z for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:04:19 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id DB048336389B; Sat, 2 Jan 2021 16:04:17 +0100 (CET) Date: Sat, 2 Jan 2021 16:04:15 +0100 From: Danny Milosavljevic Message-ID: <20210102160415.30fcb7e8@scratchpost.org> In-Reply-To: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> References: <20210101184838.21869359@scratchpost.org> <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> <20210101212242.00252cac@scratchpost.org> <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/NZW2313x+dvhmIrRptc8mQU"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --Sig_/NZW2313x+dvhmIrRptc8mQU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Leo, > > Considering the goal of Guix, it's weird that with Guix, one needs to > > store&restore /etc/passwd at all. It's state, but not very useful > > one. > > I mean that's how it is right now--but it's still weird. > > With /etc/shadow maybe there's a slightly better case, but note that > > the key > > to find stuff in /etc/shadow can't be the uid--the uid isn't even in > > there! =20 > AFAIU yes, it's state, but not one that Guix can simply do away with.=20 It's easily possible to recreate /etc/passwd from scratch if the uids are always specified in s and thus /etc/passwd would not need to be persistent state anymore. Right now everything from /etc/passwd except the uid and the comment is already specified in . So Guix can indeed simply do away with the persistent state of /etc/passwd--that's why I suggested specifying the uids in the first place. (By now I don't think that's the best way to make UIDs stable, but it's factually incorrect to assert that Guix can't simply do away with that persistent state specifically. It can.) > There is not yet a syntax for keeping secrets, which would be needed to > fully populate /etc from config.scm. Perhaps we'll get there some day. /etc/passwd does not contain secrets. Neither does /etc/group. And /etc/shadow doesn't contain uids. So there is no conflict. --Sig_/NZW2313x+dvhmIrRptc8mQU Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/wi28ACgkQ5xo1VCww uqW8Uwf+OF0uHzOoKtVm4ZVuoAzXUetEX4xil+pfwjtQc/k0oAmCNzgXFYasASVs cM7reZLqix/lWXk6FmIgMYdvgF6M9SS78aTjCWVcHTJtVuc55XrPIRVtn/P2fPwK sVd3+DkpGN7LXsIJm9DsISU9W4vNMlwgiXLpG4rUqldwwSPmrjfvfpTwMpfuBnRO Uc227svfgQS77AYk06SjyMo1JMQisrSE2x5CzkFs2a+0ceV+jy3Js8xSMXSo67RM 1L7KxGsWgeJKM87/EPP0gzuHFxJIylGysqpChLqEXtX1vIKez6I56OhuRuziodG2 9ewAyJU4vdcNCUbRTHdTGNz1b3G6qA== =IHzF -----END PGP SIGNATURE----- --Sig_/NZW2313x+dvhmIrRptc8mQU-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 15:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic Cc: 45571@debbugs.gnu.org, Leo Prikler Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095998834597 (code B ref 45571); Sat, 02 Jan 2021 15:05:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:04:43 +0000 Received: from localhost ([127.0.0.1]:60390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviSQ-0001C3-Ko for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:04:42 -0500 Received: from mail-ej1-f41.google.com ([209.85.218.41]:42485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviSP-0001Bm-FR for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:04:42 -0500 Received: by mail-ej1-f41.google.com with SMTP id d17so30599768ejy.9 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 07:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d0foqS1a9zNBwFz5S3hI4stdO0v190um719U52I8T3Y=; b=PGK7hupGbuwDmWrO7Tw2Jo022Gy/N+nD7JE44qRS1yeNryB94hh/6MI0dFjQpUi6hb vN/H8oPekAUK5tbwmOebW5UnnkJz9tMgBgXrtq3qe0MxR5ChgYeBlVVwTWYF+He1Rq4r rTOPBcQND3xpO6ZQAw8kY3El2bJi5JyGFEbEw12yB34ssHuQFo26O7KPhJnxez463PLN JujcGSTYyCbmajIRc7qqZWeRRHW8xTWrmZ4eNVtzJ1hVWiso7ws1HrQdSI3g1VzyNlCy pggK5F7JNGnnqfsrisf6kSK0BdU1zHg6zZmwQHdoYyxtjLIyfiSBaF0cbs5BsPH4dENQ zDuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d0foqS1a9zNBwFz5S3hI4stdO0v190um719U52I8T3Y=; b=hLGgJuxAZrcMxtPR8cDsaKOsBgDADHny0hhriuOQ1d8OvL+Px0FsASo5UqDJeQhcx7 G9ItAopfR03+FgWWhESLZVQDJM9IRe3oo5x2GxI3Ef/DAs1AD9HCduiAGNCaLkanjibr TfgK/Lxxv1v2inPiD/K3lxoJtX1gr9OMldmtnvFaUz2cePfMbYykjCZWOv7iRivzyDf6 cBvUwpM8gIWRG7Yx2bvqMFZ+h+CPe2zRcQclHxs8x+4xns543dJ6Pb5yibLdhwiVei3g JRX5kKRcA9+M5t2XF/HrygqzHc399oQuNB7aD5ervjc/4U520rfaEBvFPBnowsbVyVyD aEWA== X-Gm-Message-State: AOAM530fqHMYwSG8DuQVnCsFtvSq2q8GIt9Rf5SYLzt3akupvZoGoss1 wp7/AfNzdDm4ntbfi2dKdOd82lCFrxuWpiCKhtQ= X-Google-Smtp-Source: ABdhPJyG34IuSTx8LgLLYtaWb+p+5mLPZ1D6qXXDXOst6O3svOXqrprBKTDejG6ZcJurxVIRxgbAVw4IhLVh66vv3hw= X-Received: by 2002:a17:906:c82c:: with SMTP id dd12mr61392668ejb.66.1609599875714; Sat, 02 Jan 2021 07:04:35 -0800 (PST) MIME-Version: 1.0 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <20210102155002.2360e505@scratchpost.org> In-Reply-To: <20210102155002.2360e505@scratchpost.org> From: Jason Conroy Date: Sat, 2 Jan 2021 10:03:59 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000d291aa05b7ec2c15" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d291aa05b7ec2c15 Content-Type: text/plain; charset="UTF-8" Hi Danny, On Sat, Jan 2, 2021 at 9:50 AM Danny Milosavljevic wrote: > > >From the solutions we do have so far, I believe that making user > > > accounts an explicit part of service configuration (in what shape may > > > still be up for debate), > > Not everything needs to be user configurable. You suggest having these > kinds > of things especially user-configurable as a work-around for them not being > stable, right? Or do you want it in general? > > I would like to avoid them here, if only needed for that reason. > > Is there a need for using custom service UIDs? > I think if so, that is independent of this bug report, which asked for > stable UIDs and GIDs. > As far as I know, stability is sufficient for me, but Leo raised some cases where specific values would ease migration. An /etc/passwd seed file seems like another reasonable way to handle that, but I haven't investigated how difficult this change would be compared adding new knobs in operating-system. --000000000000d291aa05b7ec2c15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Danny,

On Sat, Jan 2, 2021 at 9:50 AM Danny Mil= osavljevic <dannym@scratchpost= .org> wrote:
> >From the solutions we do have so far, I believe that making user > > accounts an explicit part of service configuration (in what shape= may
> > still be up for debate),

Not everything needs to be user configurable.=C2=A0 You suggest having thes= e kinds
of things especially user-configurable as a work-around for them not being<= br> stable, right?=C2=A0 Or do you want it in general?

I would like to avoid them here, if only needed for that reason.

Is there a need for using custom service UIDs?
I think if so, that is independent of this bug report, which asked for
stable UIDs and GIDs.

As far as I know,= stability is sufficient for me, but Leo raised some cases where specific v= alues would ease migration. An /etc/passwd seed file seems like another rea= sonable way to handle that, but I haven't investigated how difficult th= is change would be compared adding new knobs in operating-system.
=
--000000000000d291aa05b7ec2c15-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 15:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic , Jason Conroy Cc: 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096007456136 (code B ref 45571); Sat, 02 Jan 2021 15:20:01 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:19:05 +0000 Received: from localhost ([127.0.0.1]:60444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvigK-0001au-OQ for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:19:05 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:34354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvigI-0001aS-2n for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:19:03 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D7QXL4T4Yz1LLyX; Sat, 2 Jan 2021 16:18:58 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D7QXL4T4Yz1LLyX DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609600738; bh=m911qi9GC1TmLaXhkVWLWJriPK/tzI9NoCr/ILL54yY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=VSO4gfVCNaPjl8Ee026i1GwWnukcd1GGYr1vbi8aez0Vmk/9n4S51/Kzrw+CffaJQ /uJPA5bV839BZwZpzQQ3e0sRiIM7J5nr8h4d/gfB8ZJ43zsilO3BmgA8ST4P9Dtff/ 0febWounrdSIfwFn2pgmbLXYMBiRShsTsvhCdBfM= Message-ID: From: Leo Prikler Date: Sat, 02 Jan 2021 16:18:57 +0100 In-Reply-To: <20210102155002.2360e505@scratchpost.org> References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <20210102155002.2360e505@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Danny, Am Samstag, den 02.01.2021, 15:50 +0100 schrieb Danny Milosavljevic: > [...] > I agree, if in addition. > > (Or if a registry is undesireable, calculate the uids by user name. > These are the possibilities. If hashing user names is too uncommon > on > UNIX elsewhere, I say that we have no /usr or /lib, so we are not > exactly doing > common things in Guix because they are common--what we do really > depends on the > merits) I don't think hashing has much merit if you have the range of 100-1000 to work with. Using the full 32 bit integer range also feels like a hack just to enable hashing, and even then hash functions targeting 32 bit integers are not known to be the most secure in this world. In other words, hashing user names into IDs is little more than theatre and while it can certainly mitigate the underlying issue in *some* cases, it is not by itself a solution. > > > From the solutions we do have so far, I believe that making user > > > accounts an explicit part of service configuration (in what shape > > > may > > > still be up for debate), > > Not everything needs to be user configurable. You suggest having > these kinds > of things especially user-configurable as a work-around for them not > being > stable, right? Or do you want it in general? I believe there might be a general utility for that if we're not going to use an existing passwd as oracle. In that case, you would need a way of claiming those IDs from the config.scm. Other than that, I believe you pointed out an NFS example, where it could also be beneficial to sync up user/system accounts with the IDs they have on other machines within the network. Of course, if all machines within the network use Guix, that point is moot, but there might be a case when you want to play nice with that one old Debian server. > I would like to avoid them here, if only needed for that reason. > > (Also, if they are user-configurable, then it's much easier for uid > collisions > to happen than if Guix manages them) Sure, but either way we'll need a collision checker, will we not? > So after thinking about it some more, I disagree that that is the > best option > for this specific problem. > > In my opinion, the best option here is all of these things: > > (1) To document that you need to seed /etc/passwd (for Docker etc) > (2) For guix system container to default to the host's /etc/passwd > and > (3) For guix system container to add and retain (!) its own > /etc/passwd for > accounts only it has (merged together with the host's /etc/passwd for > ease > of implementation) That's also a solution and I think I'd prefer that over spamming IDs throughout the codebase. > The suggestions I made before that would obsolete /etc/passwd storage > got > watered down to a version where they don't obsolete /etc/passwd > storage and > thus I oppose doing them in that form. It would be making the stuff > more > complicated--and now you'd have TWO /etc/passwd: > > * one /etc/template-passwd (for the uid registry) > (might as well integrate that into guix as a scheme file, though), > * and one /etc/passwd with the currently created users. > > This seems to be excessive just for making uids stable. FWIW I think taking the passwd-seed as a file-like object, that defaults to using the host's /etc/passwd might work here, but I'm not completely sure. > > That seems reasonable to me. As for representation, I think there's > > value > > decoupling these settings from a service's own config so that > > support for > > custom UIDs/GIDs remains consistent across services. > > Is there a need for using custom service UIDs? > I think if so, that is independent of this bug report, which asked > for > stable UIDs and GIDs. I agree, the discourse regarding that has been muddled a bit, but since custom implies stable I don't think this option can be completely discarded. Of course, both stability and customization are also given by a passwd-seed, so if we choose that implementation, other means of customization might not be needed. Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 15:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096011096728 (code B ref 45571); Sat, 02 Jan 2021 15:26:01 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:25:09 +0000 Received: from localhost ([127.0.0.1]:60448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvimC-0001kS-JY for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:25:08 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:39067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvimA-0001kJ-PM for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:25:07 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D7QgP0KSgz1LLyX; Sat, 2 Jan 2021 16:25:04 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D7QgP0KSgz1LLyX DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609601105; bh=nYRUMIPg8JAWC4vDU46samMIU9VTEuhjsYM+LGtMPc8=; h=Subject:From:To:Date:In-Reply-To:References:From; b=DZKy8FfN3wv2MGuQNvlXwNFn3nwgBn11HM2/9Bs0BJ1DvKNcUz1w1OEdj5n5njB4B /TeR9HPMR3M7qMjdgYPTszh7ut82og3BrtvBamUBaoYmy7WxrxNatjd+HMmvMjplys uKWOoY7/ok/jSZDJP8L1M7IQlxpZ0ABh60IwuvQM= Message-ID: <95f76be4dfebc473e8f4436464978a26296d2f57.camel@student.tugraz.at> From: Leo Prikler Date: Sat, 02 Jan 2021 16:25:04 +0100 In-Reply-To: <20210102160415.30fcb7e8@scratchpost.org> References: <20210101184838.21869359@scratchpost.org> <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> <20210101212242.00252cac@scratchpost.org> <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <20210102160415.30fcb7e8@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Danny, Am Samstag, den 02.01.2021, 16:04 +0100 schrieb Danny Milosavljevic: > Hi Leo, > > > > Considering the goal of Guix, it's weird that with Guix, one > > > needs to > > > store&restore /etc/passwd at all. It's state, but not very > > > useful > > > one. > > > I mean that's how it is right now--but it's still weird. > > > With /etc/shadow maybe there's a slightly better case, but note > > > that > > > the key > > > to find stuff in /etc/shadow can't be the uid--the uid isn't even > > > in > > > there! > > AFAIU yes, it's state, but not one that Guix can simply do away > > with. > > It's easily possible to recreate /etc/passwd from scratch if the uids > are > always specified in s and thus /etc/passwd would not > need to > be persistent state anymore. Right now everything from /etc/passwd > except > the uid and the comment is already specified in . > > So Guix can indeed simply do away with the persistent state of > /etc/passwd--that's why I suggested specifying the uids in the first > place. > > (By now I don't think that's the best way to make UIDs stable, but > it's > factually incorrect to assert that Guix can't simply do away with > that > persistent state specifically. It can.) > > > There is not yet a syntax for keeping secrets, which would be > > needed to > > fully populate /etc from config.scm. Perhaps we'll get there some > > day. > > /etc/passwd does not contain secrets. Neither does /etc/group. > > And /etc/shadow doesn't contain uids. > > So there is no conflict. Point taken, it is indeed possibly to do away with one of those files, but looking at them as a trio (as one ought to imo), I don't think removing one while keeping the other(s) is the way to go. Also if you do go that route, you would need a way to specify that your passwd has hitherto been different to all other Guix installations; hence forcing you to make system account [GU]IDs configurable once again. Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 15:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Jason Conroy Cc: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096017647751 (code B ref 45571); Sat, 02 Jan 2021 15:37:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:36:04 +0000 Received: from localhost ([127.0.0.1]:60454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviwl-00020w-NF for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:36:04 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:41063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviwi-00020U-C6 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:36:01 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D7Qvx07BFz1LLyX; Sat, 2 Jan 2021 16:35:56 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D7Qvx07BFz1LLyX DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609601757; bh=A71hr1tziO+FjWpB+Id8BND5x5AoZvKMsCuPGhCaOws=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Omj0n0cD9hH2zNLeKzKoAGqmaXlcAjcyOdZk/YR8U46HvZGPLkaEr5eRaVJXrU2Y1 Erng2+LtZGjzzY3DfaR2V1n8TSnNJSs/AZYFfZN29mea3QHSSnWBg10u3W7R5k3YRD EeyCv52BQXkvlhf1gc9kBvMQ+FEINNeeEpn/XoiY= Message-ID: From: Leo Prikler Date: Sat, 02 Jan 2021 16:35:56 +0100 In-Reply-To: References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello Jason, Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy: > On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler < > leo.prikler@student.tugraz.at> wrote: > > Hi Jason, > > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy: > > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler < > > > leo.prikler@student.tugraz.at> wrote: > > > > Hi Danny, > > > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > > > Milosavljevic: > > > > > Hi Leo, > > > > > > > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > > > > Leo Prikler wrote: > > > > > > > > > > > > And it indeed is possible to add (uid 4711) in the > > literal > > > > and it > > > > > > > will work > > > > > > > just fine. > > > > > > I'm aware you're joking, or at least I hope you are, > > > > > > > > > > What? It's perfectly reasonable for a distribution to have > > > > stable > > > > > system > > > > > user ids. > > > > > > My reaction to this was not that defaults are bad, but that > > > dispersing numeric literals throughout the code is. Collectively > > > these values specify the contents of a registry, so that registry > > > might as well be located centrally. Or at least, there should be > > some > > > mechanism to ensure that two services can't claim the same > > default > > > ID, otherwise the collision will not manifest until somebody > > > instantiates a system with the colliding services. > > I think it would suffice to raise a condition from shadow.scm, much > > like my proposed fix for #45570. As far as development is > > concerned, > > one could add a check to see, that no conflicts exist between > > services > > extending account-service-type. > > Assuming that authors of new services tend to choose the lowest free > ID, is this validation sufficient to ensure that two services checked > around the same time by different authors won't collide? No, you'd need to lint the services in the pre-push hook. That would not be the biggest deal though, we already authenticate the commits and check whether the NEWS file is broken before pushing, for instance. I believe it could also be checked without actually instantiating that system, but don't quote me on that. > > > > From the solutions we do have so far, I believe that making > > user > > > > accounts an explicit part of service configuration (in what > > shape > > > > may > > > > still be up for debate), with reasonable defaults including > > numeric > > > > UIDs and GIDs (at least) for essential services such as GDM > > sounds > > > > like > > > > the best option. WDYT? > > > > > > > > Regards, > > > > Leo > > > > > > That seems reasonable to me. As for representation, I think > > there's > > > value decoupling these settings from a service's own config so > > that > > > support for custom UIDs/GIDs remains consistent across services. > > In this case I'd agree with Danny, that asking users to update two > > fields to get one service working puts an excessive burden on > > them. > > Leo, I'm not sure what you mean by updating two fields. Are you > saying that some services already permit manual selection of UIDs? I > was proposing setting that value in the "users" section of operating- > system (or elsewhere) rather than setting it in the "services" > section, but not both places. As far as I'm aware, no service so far do that, but there are some, that don't set up the user (e.g. mpd). However, I don't think, that's the way to go for services like gdm. If you decoupled the gdm user and group from its service specification, you'd need to modify three operating-system fields to add gdm as opposed to one. If the gdm user and group were configuration, you could instead specify them with modify-services or gdm-service-type itself. > Since Guix already uses a central allocator for UIDs and GIDs > (implemented using simple counters), I was imagining a model where > the decision is still made centrally, but with different inputs: 1) a > global mapping from user/group name to default ID; and 2) a similar > name-to-ID mapping in operating-system where users specify their > overrides. I'm not sure how well that'd work together with account-service-type. You'd have to find a novel way of extending it, that's for sure. > > To > > be fair, I don't even necessarily think, that making the full > > account > > configurable is a good idea, unless someone wants to argue, that > > there's value in potentially giving those accounts shell access. > > The thought of making other parts of the account configurable > occurred to me, but I couldn't come up with any serious use cases > either. As far as I'm aware, nologin exists for a good reason. Regards, Leo From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Cc: Danny Milosavljevic , 45571@debbugs.gnu.org Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096031419727 (code B ref 45571); Sat, 02 Jan 2021 16:00:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:59:01 +0000 Received: from localhost ([127.0.0.1]:60464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvjIz-0002We-3y for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:59:01 -0500 Received: from mail-ed1-f44.google.com ([209.85.208.44]:34137) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvjIw-0002WP-R0 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:58:59 -0500 Received: by mail-ed1-f44.google.com with SMTP id dk8so22471051edb.1 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 07:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DTp8NQfOp+MVeQlyX86qkQhlRG2tPvJKv3kNEVdTFMU=; b=nbYhiafFBLpEY/vCxvVJzZ6tUR/VuBb9B5VxK8AsnWuKlUM0V605eIORC0mjNm9FxM P9Z8TRujC6+lEd2rOJTfum4HN3QWcFn6SHkp/KsJrcKU5R1HzwyAPEgceYET6zsUTFBv ytWA4+FScy3KfeScKKbyizmFI07/8hdKdvhp2q8qXK2zjHO2cyFMptoOKqzsTYsPDmRQ MCN92bkrhWLokfygNdTVx32eNtcZsuKT53/IcfzedB305yIvaYGlvxBRoQiaNHMYFhyp gNAJ1b44GEvDimRA59agTO4eeiC8ZjAibDAMlN3ki4O/wLpqMH2ZuJ4aXkFmYIVQGYr+ 9HSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DTp8NQfOp+MVeQlyX86qkQhlRG2tPvJKv3kNEVdTFMU=; b=DzDo0tafUU8puzkJ7+faJFjZIdnCnLsCsygo733afw/DYbeo/OYV/WAi0SsrXR/s6w 3ibSTu9YITSkQcm+xT4gs7IK4nbBxYnvSWArN1AMlF237KSorq07Ysxix9Rfqc+z8wvb mo1bG89AIoL/WL5QOAZFCrbv7Fj0/ILh2+bsUxzOpwvuBgh0EhpNqNMj1d5Rq7EgRjHI heN1JrYuKKBEp7VkXZmeTARjp/K4jcE1CysqK9Cm/ivIHEsEN0EGh/Rd6WAd/f+b/MRG L8vADoUv+xdzANIMrFiPJ8U//z+zf28dM5SvyxI2BPONjNXGBJ5KHNF55bj2UasHZo6O pDUQ== X-Gm-Message-State: AOAM532yr/QQua81gjK4FYLGzaXP0hsJ3GQ8smQYI/19CEp5CGoFuHFP DEIvjz7H9rcDtsZgIiCtM4M/twmJoVWgQQYI9Sk= X-Google-Smtp-Source: ABdhPJxVVQPpA+DJWte+tUu8Vh+XUYlcPNj2mDbxY1YI856Uok+Nw5dfxMfWCz/lEsBt1WOtsGUYs0qNPYJtwObN4FY= X-Received: by 2002:aa7:c60c:: with SMTP id h12mr64145134edq.145.1609603132913; Sat, 02 Jan 2021 07:58:52 -0800 (PST) MIME-Version: 1.0 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> In-Reply-To: From: Jason Conroy Date: Sat, 2 Jan 2021 10:58:16 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000f77d7505b7eceed0" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000f77d7505b7eceed0 Content-Type: text/plain; charset="UTF-8" Hi Leo, On Sat, Jan 2, 2021 at 10:35 AM Leo Prikler wrote: > Hello Jason, > Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy: > > On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler < > > leo.prikler@student.tugraz.at> wrote: > > > Hi Jason, > > > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy: > > > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler < > > > > leo.prikler@student.tugraz.at> wrote: > > > > > Hi Danny, > > > > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > > > > Milosavljevic: > > > > > > Hi Leo, > > > > > > > > > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > > > > > Leo Prikler wrote: > > > > > > > > > > > > > > And it indeed is possible to add (uid 4711) in the > > > literal > > > > > and it > > > > > > > > will work > > > > > > > > just fine. > > > > > > > I'm aware you're joking, or at least I hope you are, > > > > > > > > > > > > What? It's perfectly reasonable for a distribution to have > > > > > stable > > > > > > system > > > > > > user ids. > > > > > > > > My reaction to this was not that defaults are bad, but that > > > > dispersing numeric literals throughout the code is. Collectively > > > > these values specify the contents of a registry, so that registry > > > > might as well be located centrally. Or at least, there should be > > > some > > > > mechanism to ensure that two services can't claim the same > > > default > > > > ID, otherwise the collision will not manifest until somebody > > > > instantiates a system with the colliding services. > > > I think it would suffice to raise a condition from shadow.scm, much > > > like my proposed fix for #45570. As far as development is > > > concerned, > > > one could add a check to see, that no conflicts exist between > > > services > > > extending account-service-type. > > > > Assuming that authors of new services tend to choose the lowest free > > ID, is this validation sufficient to ensure that two services checked > > around the same time by different authors won't collide? > No, you'd need to lint the services in the pre-push hook. That would > not be the biggest deal though, we already authenticate the commits and > check whether the NEWS file is broken before pushing, for instance. I > believe it could also be checked without actually instantiating that > system, but don't quote me on that. > Ok, that seems achievable. I would only point out that with a central UID registry you get that validation "for free" in the form of a Git merge conflict. > > > > > From the solutions we do have so far, I believe that making > > > user > > > > > accounts an explicit part of service configuration (in what > > > shape > > > > > may > > > > > still be up for debate), with reasonable defaults including > > > numeric > > > > > UIDs and GIDs (at least) for essential services such as GDM > > > sounds > > > > > like > > > > > the best option. WDYT? > > > > > > > > > > Regards, > > > > > Leo > > > > > > > > That seems reasonable to me. As for representation, I think > > > there's > > > > value decoupling these settings from a service's own config so > > > that > > > > support for custom UIDs/GIDs remains consistent across services. > > > In this case I'd agree with Danny, that asking users to update two > > > fields to get one service working puts an excessive burden on > > > them. > > > > Leo, I'm not sure what you mean by updating two fields. Are you > > saying that some services already permit manual selection of UIDs? I > > was proposing setting that value in the "users" section of operating- > > system (or elsewhere) rather than setting it in the "services" > > section, but not both places. > As far as I'm aware, no service so far do that, but there are some, > that don't set up the user (e.g. mpd). However, I don't think, that's > the way to go for services like gdm. If you decoupled the gdm user and > group from its service specification, you'd need to modify three > operating-system fields to add gdm as opposed to one. If the gdm user > and group were configuration, you could instead specify them with > modify-services or gdm-service-type itself. > > > Since Guix already uses a central allocator for UIDs and GIDs > > (implemented using simple counters), I was imagining a model where > > the decision is still made centrally, but with different inputs: 1) a > > global mapping from user/group name to default ID; and 2) a similar > > name-to-ID mapping in operating-system where users specify their > > overrides. > I'm not sure how well that'd work together with account-service-type. > You'd have to find a novel way of extending it, that's for sure. > > > > To > > > be fair, I don't even necessarily think, that making the full > > > account > > > configurable is a good idea, unless someone wants to argue, that > > > there's value in potentially giving those accounts shell access. > > > > The thought of making other parts of the account configurable > > occurred to me, but I couldn't come up with any serious use cases > > either. > As far as I'm aware, nologin exists for a good reason. > No arguments there. :) I thought your point was that we don't have a compelling reason to let the end user replace it with something else. --000000000000f77d7505b7eceed0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Leo,

On Sat, Jan 2, 2021 at 10:35 AM Leo Prikle= r <leo.prikler@student.= tugraz.at> wrote:
Hello Jason,
Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy:
> On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler <
> leo= .prikler@student.tugraz.at> wrote:
> > Hi Jason,
> > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy:
> > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler <
> > > leo.prikler@student.tugraz.at> wrote:
> > > > Hi Danny,
> > > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > > > Milosavljevic:
> > > > > Hi Leo,
> > > > >
> > > > > On Sat, 02 Jan 2021 00:16:45 +0100
> > > > > Leo Prikler <leo.prikler@student.tugraz.at> wrot= e:
> > > > >
> > > > > > > And it indeed is possible to add (uid 47= 11) in the
> > literal
> > > > and it
> > > > > > > will work
> > > > > > > just fine.=C2=A0
> > > > > > I'm aware you're joking, or at least = I hope you are,
> > > > >
> > > > > What?=C2=A0 It's perfectly reasonable for a di= stribution to have
> > > > stable
> > > > > system
> > > > > user ids.
> > >
> > > My reaction to this was not that defaults are bad, but that<= br> > > > dispersing numeric literals throughout the code is. Collecti= vely
> > > these values specify the contents of a registry, so that reg= istry
> > > might as well be located centrally. Or at least, there shoul= d be
> > some
> > > mechanism to ensure that two services can't claim the sa= me
> > default
> > > ID, otherwise the collision will not manifest until somebody=
> > > instantiates a system with the colliding services.
> > I think it would suffice to raise a condition from shadow.scm, mu= ch
> > like my proposed fix for #45570.=C2=A0 As far as development is > > concerned,
> > one could add a check to see, that no conflicts exist between
> > services
> > extending account-service-type.
>
> Assuming that authors of new services tend to choose the lowest free > ID, is this validation sufficient to ensure that two services checked<= br> > around the same time by different authors won't collide?
No, you'd need to lint the services in the pre-push hook.=C2=A0 That wo= uld
not be the biggest deal though, we already authenticate the commits and
check whether the NEWS file is broken before pushing, for instance.=C2=A0 I=
believe it could also be checked without actually instantiating that
system, but don't quote me on that.

Ok, that seems achievable. I would only point out that with a central UID = registry you get that validation "for free" in the form of a Git = merge conflict.


> > > > From the solutions we do have so far, I believe that ma= king
> > user
> > > > accounts an explicit part of service configuration (in = what
> > shape
> > > > may
> > > > still be up for debate), with reasonable defaults inclu= ding
> > numeric
> > > > UIDs and GIDs (at least) for essential services such as= GDM
> > sounds
> > > > like
> > > > the best option.=C2=A0 WDYT?
> > > >
> > > > Regards,
> > > > Leo
> > >
> > > That seems reasonable to me. As for representation, I think<= br> > > there's
> > > value decoupling these settings from a service's own con= fig so
> > that
> > > support for custom UIDs/GIDs remains consistent across servi= ces.
> > In this case I'd agree with Danny, that asking users to updat= e two
> > fields to get one service working puts an excessive burden on
> > them.=C2=A0
>
> Leo, I'm not sure what you mean by updating two fields. Are you > saying that some services already permit manual selection of UIDs? I > was proposing setting that value in the "users" section of o= perating-
> system (or elsewhere) rather than setting it in the "services&quo= t;
> section, but not both places.
As far as I'm aware, no service so far do that, but there are some,
that don't set up the user (e.g. mpd).=C2=A0 However, I don't think= , that's
the way to go for services like gdm.=C2=A0 If you decoupled the gdm user an= d
group from its service specification, you'd need to modify three
operating-system fields to add gdm as opposed to one.=C2=A0 If the gdm user=
and group were configuration, you could instead specify them with
modify-services or gdm-service-type itself.

> Since Guix already uses a central allocator for UIDs and GIDs
> (implemented using simple counters), I was imagining a model where
> the decision is still made centrally, but with different inputs: 1) a<= br> > global mapping from user/group name to default ID; and 2) a similar > name-to-ID mapping in operating-system where users specify their
> overrides.
I'm not sure how well that'd work together with account-service-typ= e.
You'd have to find a novel way of extending it, that's for sure.
> > To
> > be fair, I don't even necessarily think, that making the full=
> > account
> > configurable is a good idea, unless someone wants to argue, that<= br> > > there's value in potentially giving those accounts shell acce= ss.=C2=A0
>
> The thought of making other parts of the account configurable
> occurred to me, but I couldn't come up with any serious use cases<= br> > either.
As far as I'm aware, nologin exists for a good reason.
=

No arguments there. :) I thought your point was that w= e don't have a compelling reason to let the end user replace it with so= mething else.
--000000000000f77d7505b7eceed0-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for all accounts Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 06 Jan 2021 10:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic Cc: 45571@debbugs.gnu.org, Leo Prikler Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160992739616545 (code B ref 45571); Wed, 06 Jan 2021 10:04:02 +0000 Received: (at 45571) by debbugs.gnu.org; 6 Jan 2021 10:03:16 +0000 Received: from localhost ([127.0.0.1]:43491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kx5eu-0004Il-Gt for submit@debbugs.gnu.org; Wed, 06 Jan 2021 05:03:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kx5et-0004IQ-0W for 45571@debbugs.gnu.org; Wed, 06 Jan 2021 05:03:15 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57462) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kx5el-0003G0-K8; Wed, 06 Jan 2021 05:03:07 -0500 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=41416 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kx5ek-0000qZ-P0; Wed, 06 Jan 2021 05:03:07 -0500 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20210101184838.21869359@scratchpost.org> <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> <20210101212242.00252cac@scratchpost.org> <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <20210102160415.30fcb7e8@scratchpost.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 =?UTF-8?Q?Niv=C3=B4se?= an 229 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 06 Jan 2021 11:03:04 +0100 In-Reply-To: <20210102160415.30fcb7e8@scratchpost.org> (Danny Milosavljevic's message of "Sat, 2 Jan 2021 16:04:15 +0100") Message-ID: <87pn2io013.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Danny, Danny Milosavljevic skribis: > It's easily possible to recreate /etc/passwd from scratch if the uids are > always specified in s and thus /etc/passwd would not need to > be persistent state anymore. Right now everything from /etc/passwd except > the uid and the comment is already specified in . > > So Guix can indeed simply do away with the persistent state of > /etc/passwd--that's why I suggested specifying the uids in the first plac= e. I don=E2=80=99t think it can: UID/GID allocation is stateful by nature beca= use you don=E2=80=99t want to reuse a recently-used ID right away. See the allocation strategy in (gnu build accounts). Ludo=E2=80=99. From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for system accounts in a container References: In-Reply-To: Resent-From: Brendan Tildesley Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 07 Apr 2021 07:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: "45571@debbugs.gnu.org" <45571@debbugs.gnu.org> Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.161777964328777 (code B ref 45571); Wed, 07 Apr 2021 07:15:01 +0000 Received: (at 45571) by debbugs.gnu.org; 7 Apr 2021 07:14:03 +0000 Received: from localhost ([127.0.0.1]:42894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lU2O3-0007U5-82 for submit@debbugs.gnu.org; Wed, 07 Apr 2021 03:14:03 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:10814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lU2O1-0007TU-9t for 45571@debbugs.gnu.org; Wed, 07 Apr 2021 03:14:02 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4FFbGp6FcqzQk1x for <45571@debbugs.gnu.org>; Wed, 7 Apr 2021 09:13:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:subject:subject :message-id:from:from:date:date:received; s=mail20150812; t= 1617779631; bh=yUiwIOgWSYCQ3dmSofjADgMYCLvh0Tb4KyVtPNwkAyE=; b=x U3zffCu7ANujItaOxcYurcR5vTBQOKawEOEEeBrhrNPGyKdi4G72RSYhOEjRbdvp dU4+KKZqLo6A0TWpOV9UpiWV+kJl2pB6D7bw+sHcP2/JGpm8VjZ4aPGycW8x4zW0 dINWuKCijylPIvQcwazErnbSjep9E9DlJAD2lLgzK9ofeYzUIMKqZ+se+vcfHH8L efdZz/kiI3MCx3tI4qD0NrILSyagEWCVDVOBhhQRquvMjRSFCN3UcY1xBcIS/Y57 tMjvZSfAu8iOL2ul5LeZvf5kvsOEOnVLNy8q2HZA9nHFNbkG7sA5zk7G2TzRqLKP DFD/c0EA+OQoTr928hyow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1617779632; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=/3a9s7wmhBI2n+vH9U856kVFHWyryGc4lNhBkfpbUaA=; b=f+m2IPxPNqVtwoqVHOuVh/OI/zzPNOpEhfJ/aqylKubK0hbh+b/67VREjlQYTajAcbtP5P zkfEHG2yYMhynnAMWFa/H1F4zSKE+pJE5H4R8W635+Idv1OTCWcwlWb4fiejAYHTpizRdW S4oAf0be+J9mPEpBeGo6r4alQL8Knw1W05uSVPLbc9fYwE2CS6ZQT7UHTiei9nD1lnO+l3 rSMiViEiPKcZ6FMmddLVmo2PwX2hIcwCh+1hlVXet1PTyyUlCZWGFvFyvK2HaxKfKEQj3k 0cdI/jmh9V1R8l02+ZXInxgZ/bVGss1Zl8irmZyO9iT4tMmIEqsJDJNp81YREQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id csWez-FVlWRK for <45571@debbugs.gnu.org>; Wed, 7 Apr 2021 09:13:51 +0200 (CEST) Date: Wed, 7 Apr 2021 09:13:50 +0200 (CEST) From: Brendan Tildesley Message-ID: <887823078.43817.1617779630834@office.mailbox.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43816_735588192.1617779630831" X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: * X-Rspamd-Score: 0.89 / 15.00 / 15.00 X-Rspamd-Queue-Id: 8CA6315F8 X-Rspamd-UID: e6542c X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) ------=_Part_43816_735588192.1617779630831 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It may be useful to see what Nix does. Nix has many static id, with the comment: # IMPORTANT! # We only add static uids and gids for services where it is not feasible # to change uids/gids on service start, in example a service with a lot of # files. Please also check if the service is applicable for systemd's https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix ------=_Part_43816_735588192.1617779630831 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
It may be useful to see what Nix does.

Nix has many static id, with the comment:

# IMPORTANT!
# We only add static uids and gids for services where it is not feasible
# to change uids/gids on service start, in example a service with a lot of
# files. Please also check if the service is applicable for systemd's

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix
------=_Part_43816_735588192.1617779630831-- From unknown Sat Sep 13 11:38:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Support stable uids and gids for system accounts in a container Resent-From: Arun Isaac Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 10 Jun 2021 06:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: <45571@debbugs.gnu.org> Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16233049524493 (code B ref 45571); Thu, 10 Jun 2021 06:03:02 +0000 Received: (at 45571) by debbugs.gnu.org; 10 Jun 2021 06:02:32 +0000 Received: from localhost ([127.0.0.1]:35211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrDlw-0001AP-ET for submit@debbugs.gnu.org; Thu, 10 Jun 2021 02:02:32 -0400 Received: from mugam.systemreboot.net ([139.59.75.54]:38750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrDlt-0001AD-1a for 45571@debbugs.gnu.org; Thu, 10 Jun 2021 02:02:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=systemreboot.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:To:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+wtKnzhLcVsHsQ7ZIWA8NCrKelVidGl6EVUlgwHG7g8=; b=cU4O/NaBkoVIGHLec3G4u3N3th ZUgd0zpVCdDBK9Crbz9FwjXIh5FefyKJYqFgRV2bDjmL/HSJcyVwWV23ytXs6qYykfmT2QRwcAxeC XBFlvuA1H/tjlvjE00d2Tmofurzh0pRHqhr41Kyt8JiqMt1Tdu9lG2mZVc0e4avsKoLnBz19t9dZi lOKd8PEMyfUIsmjP4uOzidd4O3gIS56gkv+hQm1r0akegG/kscdeZY1RysyUo/56WHnlpx1tbQY3p oB9fMDXfsDUN4rA/iZemN/QCruAmY7L+YS5nzYZe3evoNZ9AxWX4Pjr0JFczXj0xsLP3wbqdn4k+e qFSsuYdg==; Received: from [192.168.2.1] (helo=steel) by systemreboot.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lrDlq-0003Ae-3w for 45571@debbugs.gnu.org; Thu, 10 Jun 2021 11:32:26 +0530 From: Arun Isaac In-Reply-To: <887823078.43817.1617779630834@office.mailbox.org> References: <887823078.43817.1617779630834@office.mailbox.org> Date: Thu, 10 Jun 2021 11:32:25 +0530 Message-ID: <878s3ijlzi.fsf@systemreboot.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hi all, For many services, extending the activation-service-type with a gexp that can chown the necessary files is a good enough solution. This is how I work around the problem of unstable uids/gids in my guix system containers. Regards, Arun --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFPBAEBCAA5FiEEf3MDQ/Lwnzx3v3nTLiXui2GAK7MFAmDBqvEbHGFydW5pc2Fh Y0BzeXN0ZW1yZWJvb3QubmV0AAoJEC4l7othgCuzer4H/2xANi0NJxY2hZEsSFUA xAzOhxWRBSWe/orc6z+1q2+HdbRWJ35ijuc124Ob+Zu9iiO8217/P2oEvAzHB38g nAZEj+c8yWYjsR2KQUq1xYT74DtoxqmaazwjKDgqogXfl+mXbvTYMWasIubrG55f +OZxBZkst9utK1xIcPHYi2MQXBNyZrf8aYpwDATudxohNmwraMakjsJPoJDjxs+5 u+MrjH/5eYlCoey16ItNP/UrGf2/l34M7NzMNlgybqKlM/5uSOXgKmIVE6kEDj3S 2DvvxwqjJoaTv4kWAURbvkax/mGZ8/Jo7EFv8/qer8dT6P4Pjbqfp32fExWvW8ZX akc= =87w6 -----END PGP SIGNATURE----- --=-=-=--