From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qCxMG2GI8F9oMAAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 14:51:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id eP/aFmGI8F8EdQAAB5/wlQ (envelope-from ) for ; Sat, 02 Jan 2021 14:51:13 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9DCD29404C2 for ; Sat, 2 Jan 2021 14:51:12 +0000 (UTC) Received: from localhost ([::1]:46524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kviFK-0007G9-PY for larch@yhetil.org; Sat, 02 Jan 2021 09:51:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kviFC-0007Fu-Gv for bug-guix@gnu.org; Sat, 02 Jan 2021 09:51:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48052) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kviFC-00076h-9o for bug-guix@gnu.org; Sat, 02 Jan 2021 09:51:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kviFC-0000f5-82 for bug-guix@gnu.org; Sat, 02 Jan 2021 09:51:02 -0500 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 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 45571@debbugs.gnu.org, Leo Prikler Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.43 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 9DCD29404C2 X-Spam-Score: -2.43 X-Migadu-Scanner: scn1.migadu.com X-TUID: 92BMbBf56I8g --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--