From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id sCJUOF/Fl2I7kQAAbAwnHQ (envelope-from ) for ; Wed, 01 Jun 2022 22:00:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UGM3OF/Fl2IfDAAA9RJhRA (envelope-from ) for ; Wed, 01 Jun 2022 22:00:31 +0200 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 4182EE2D for ; Wed, 1 Jun 2022 22:00:31 +0200 (CEST) Received: from localhost ([::1]:37616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nwUW6-0000Qv-Ev for larch@yhetil.org; Wed, 01 Jun 2022 16:00:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwUVK-0000OW-8m for guix-devel@gnu.org; Wed, 01 Jun 2022 15:59:46 -0400 Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]:58846) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nwUVG-0002Zh-9l for guix-devel@gnu.org; Wed, 01 Jun 2022 15:59:41 -0400 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by laurent.telenet-ops.be with bizsmtp id dvzY270084UW6Th01vzYer; Wed, 01 Jun 2022 21:59:32 +0200 Message-ID: <91ce7e991c639c891516bad7a125937070d97efd.camel@telenet.be> Subject: Re: A corner case of broken reproducibility From: Maxime Devos To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: Felix Lechner , Guix Devel Date: Wed, 01 Jun 2022 21:59:27 +0200 In-Reply-To: <87bkvcuynd.fsf@gnu.org> References: <87leuj108h.fsf@gnu.org> <31d13a6014b14c886686bca833d926604ce3379d.camel@telenet.be> <87bkvcuynd.fsf@gnu.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-tGFwh8YuR5xx8UIgj8nJ" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1654113572; bh=5lyi6cdGHdmuyfPLERtZboW4N0PTJRuc+Q/7WLKv+DQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ONM4a/FWuZJItX/+ELfW10s3fKPyABocbjK2AZFvw2TNj27eJCEB9a7avx50jUq7t PdDAsUHQj3oxxzKmtAHPqmm/FvBAd8tAWCohMgHBNZRQkcf3+CJ+NmEDBlnJwpmbB2 XPoXR5Z1AQmxL3HHrDVkYvz/QYe8R3U6nXoOWuEiltmmwasISU0f85LuDGz2OlEzPz k3T5cVqnHBSREEhl/seEaYBtN9GeI3xXW8ikeHunpEVDU/mL4z6xyHE3+zSmk5JGc/ sZQUfi4b46uoRIvXMBAem78pojSWLq3ACR6+mcaMKfT614jhRz1KzQ+Zb+M9vWRgeC sFjJuSn+f00mg== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654113631; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=5lyi6cdGHdmuyfPLERtZboW4N0PTJRuc+Q/7WLKv+DQ=; b=GjzQKVjqY1heALJSkBoTK1WZemUi/HBjTh4PaEPXoWdsb7Wn+J4+iNZ/OPtW4PpLpLe3K8 1wzUycMknwjFPK9CysqibMWiV/kZ0ljPO75oFwnr0eb/jUEINzMEEbpa+39uHKPWibsJJ3 RxruYcjXbaMt73H2WCx0w3358mnbtbAanHTVzpSv3p0nXlJGcxEVnsbY9W5BFzzZub9E3T lj05Dj6SQAR0Pw/wp97h+pY4awJbLwxVY/jYMnAyo/UDL0QNmihSb5AwYyD6pqOg2Kfuyr ecOmnPd9SvNF13C3rV5NQ91HDIW6z8IMKsSWfxmHmD0GqC41GwuAaekZUIO0dQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654113631; a=rsa-sha256; cv=none; b=MaU5gIOigaJW7F2rSVk6c/9VrhJXdZJdCBGGYeqhNcaPFsPm39gJQEDFG9QgMcvOh7Uiec dMseLm7M8J8huADKSJrms6S85iHfA5MmSa0j6aiO6vzc+o9lij71QOHmnrj3j4/f9lPwE2 umAXFI/aLGeFbeuwfutyays6H8kjsIPfOVs2Ex/LiGNuM+yrzMlvrraDZxeL91/+aeGwZV EgmmE9hyEgGjEvLQPr1psWC17xFuSoBjDHy+u9j2vTN8tkO067Wt1Q6NuY8bGReR1psDDI hFa2Foq0eHJqkQfONW/xVQuZMGOdkPi3ndy/H45KxfevTVcqAMxyFlGnAkGZAA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b="ONM4a/FW"; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -8.13 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b="ONM4a/FW"; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 4182EE2D X-Spam-Score: -8.13 X-Migadu-Scanner: scn0.migadu.com X-TUID: H5xxZCwUFMyN --=-tGFwh8YuR5xx8UIgj8nJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s schreef op wo 01-06-2022 om 18:38 [+0200]: > Things that seem missing here to me: >=20 > =C2=A0=C2=A0 * a mechanism for remembering that an uid is still in use ev= en > though > =C2=A0=C2=A0=C2=A0=C2=A0 the user has been removed (previously mentioned = solutions: keep > the > =C2=A0=C2=A0=C2=A0=C2=A0 uid in /etc/passwd even though it is =E2=80=98re= moved=E2=80=99, or keep a > separate > =C2=A0=C2=A0=C2=A0=C2=A0 /etc/passwd-graveyard or such, etc.).=C2=A0 For = system accounts and > user > =C2=A0=C2=A0=C2=A0=C2=A0 accounts.=C2=A0 Won't help in this particular ca= se but would make > more > =C2=A0=C2=A0=C2=A0=C2=A0 general adding/removing user accounts less fragi= le (avoid=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0 accidental reuse). How do you know that user =E2=80=9Cmaxime=E2=80=9D created today is =E2=80= =9Cthe same=E2=80=9D as that =E2=80=9Cmaxime=E2=80=9D deleted a while back?=C2=A0 You can=E2=80=99t. The point above was about remembering that uids (arbitrary unique numbers) are still in use, and only tangentially about user names (the /etc/passwd bit). We can have a mechanism for registering that an uid that hasn't an associated name anymore but might still be in use somewhere (by a process or a file) and hence shouldn't be reused automatically, without having to touch the concept of user names at all. We don't have to know that they are the same or different (though we could implement some kind of heuristic that old "foo" is the same as new "foo" if that's desired), we only need some kind of mechanism to stop automatically breaking things. > (gnu build accounts) is stateful in that it makes sure UIDs aren=E2=80=99= t > reused.=C2=A0 (This is roughly the same algorithm as used by Shadow.) It doesn't? AFAICT it only takes /etc/passwd and /etc/groups in account and there was some bug report reusing uids in system accounts after removing a service (something about tor and gdm?), adding another service and re-adding the original service or something like that. > > =C2=A0=C2=A0 * a mechanism for telling Guix =E2=80=98I'm renaming the u= ser account, > > not > > =C2=A0=C2=A0=C2=A0=C2=A0 creating and removing a new one, so keep the u= id=E2=80=99 >=20 > Every system generation stands alone though; it=E2=80=99s functional, > stateless, and all that.=C2=A0 What does =E2=80=9Crename=E2=80=9D mean in= this context? A declaration in the configuration that in the past the user "bar" has been named "foo", so if during reconfiguration Guix doesn't find "bar" in /etc/passwd but it does find "foo", it shouldn't assign a new uid and remove "foo" or such but rather change "foo:...:THIS-UID:.." entry to "bar:...:THAT-UID": (user-account (name "foo") (old-names '("bar" "baz")) (old-home-directories '("/home/bar" "/home/baz")) ; rename the old /home/bar to /home/foo [...]) It's a bit state-y though in the sense that it refers to the previous system configurations (and it wouldn't interact well with rollbacks because the old configurations wouldn't have "foo" in old-names), so some other solutions may be needed! E.g., here's an alternative solution: * Require each user to be given unique identifier (UUID?) that cannot be changed (unlike uid or username or home directory). Record the UUID in /etc/passwd or such somehow. Example: + Configuration 1 (user-account (name "foo") (uid 1234) (persistent-identifier "THE-UUID") (home-directory "/home/foo")) At first boot, this creates a foo:...:1234:...:THE-UUID entry in /etc/passwd as no user with THE-UUID exists yet. Likewise, it also creates /home/foo + Configuration 2: (user-account (name "bar") (user 4321) (persistent-identifier "THE-UUID") =20 (home-directory "/home/bar")) At reconfiguration, Guix notices that THE-UUID already exists, so it renames the old home directory /home/foo (listed in /etc/passwd) to /home/bar, chowns /home/foo to 4321, and changes the passwd entry to use 4321 as uid and "bar" as username + Rolling-back to configuration 1: likewise. A complication however: home directories on external media that might not even be attached during reconfiguration, or external media that are read-only. And not being able to rename the THE-UUID is a limitation. Greetings, Maxime. --=-tGFwh8YuR5xx8UIgj8nJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYpfFHxccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7sSFAQCt+h7AExO8lfJgC6say+azNrd4 /UxvtrpSOU7KB9U6PQEAtTexrYFIUgx2ojIQxEfp2Rde+ZrDpI5GAjfGxWruVA0= =IJNh -----END PGP SIGNATURE----- --=-tGFwh8YuR5xx8UIgj8nJ--