From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 02 09:50:26 2021 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 To: Jason Conroy Subject: Re: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts 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-Debbugs-Envelope-To: 45571 Cc: 45571@debbugs.gnu.org, Leo Prikler 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--