From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MOnaEMKE718RPQAA0tVLHw (envelope-from ) for ; Fri, 01 Jan 2021 20:23:30 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 0LqpDMKE71/jWgAAbx9fmQ (envelope-from ) for ; Fri, 01 Jan 2021 20:23:30 +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 85CA59404D0 for ; Fri, 1 Jan 2021 20:23:29 +0000 (UTC) Received: from localhost ([::1]:36736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvQxI-0004H9-Kf for larch@yhetil.org; Fri, 01 Jan 2021 15:23:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46312) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvQww-0004H0-BL for bug-guix@gnu.org; Fri, 01 Jan 2021 15:23:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51634) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvQww-0000bl-46 for bug-guix@gnu.org; Fri, 01 Jan 2021 15:23:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvQwv-0008TI-Vx for bug-guix@gnu.org; Fri, 01 Jan 2021 15:23:01 -0500 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-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: 85CA59404D0 X-Spam-Score: -2.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: OAMGX7qHYp0J --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--