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 EKKJBeDM7196RwAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 01:31:12 +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 QE6EAeDM71+bSQAAB5/wlQ (envelope-from ) for ; Sat, 02 Jan 2021 01:31:12 +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 74160940341 for ; Sat, 2 Jan 2021 01:31:11 +0000 (UTC) Received: from localhost ([::1]:40942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvVl7-0005K5-53 for larch@yhetil.org; Fri, 01 Jan 2021 20:31:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvVl0-0005Jv-RZ for bug-guix@gnu.org; Fri, 01 Jan 2021 20:31:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51764) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvVl0-0007Pn-Kd for bug-guix@gnu.org; Fri, 01 Jan 2021 20:31:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvVl0-0007YH-HY for bug-guix@gnu.org; Fri, 01 Jan 2021 20:31:02 -0500 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-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: , 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: 74160940341 X-Spam-Score: -2.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: D3VTyfY+068b --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--