GNU logs - #45571, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#45571: Support stable uids and gids for system accounts in a container
Resent-From: Jason Conroy <conjaroy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 31 Dec 2020 18:20:01 +0000
Resent-Message-ID: <handler.45571.B.160943875717476 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 45571 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Jason Conroy <conjaroy@HIDDEN>
Date: Thu, 31 Dec 2020 13:18:36 -0500
Message-ID: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000016c49b05b7c6a996"
Received-SPF: pass client-ip=2a00:1450:4864:20::62e;
 envelope-from=conjaroy@HIDDEN; helo=mail-ej1-x62e.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--00000000000016c49b05b7c6a996
Content-Type: text/plain; charset="UTF-8"

If I understand correctly, the container script produced by "guix system
container" will allocate the same uid and gid for a service on each
execution, but only if the corresponding entry in the service list has the
same absolute position as it did before. I.e., if the services are
reordered or if there are additions and removals, it's unlikely that the id
allocations will be the same.

As long as a container's filesystems don't outlive the container itself,
this works fine. But when host filesystems are bind-mounted inside the
container with the --share or --expose options, it's important that each
incarnation of a service uses the same uid and gid, because the bind mounts
might be used to hold persistent state for those services.

At first, I thought that I could just define static uids and gids for these
system accounts by adding corresponding user-account and user-group
entries. But this doesn't work: rather than changing how the system
accounts are defined for these services, it results in /etc files with
duplicate entries. (See https://issues.guix.gnu.org/45570 for details.)

--00000000000016c49b05b7c6a996
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>If I understand correctly, the container script produ=
ced by &quot;guix system container&quot; will allocate the same uid and gid=
 for a service on each execution, but only if the corresponding entry in th=
e service list has the same absolute position as it did before. I.e., if th=
e services are reordered or if there are additions and removals, it&#39;s u=
nlikely that the id allocations will be the same.</div><div><br></div><div>=
As long as a container&#39;s filesystems don&#39;t outlive the container it=
self, this works fine. But when host filesystems are bind-mounted inside th=
e container with the --share or --expose options, it&#39;s important that e=
ach incarnation of a service uses the same uid and gid, because the bind mo=
unts might be used to hold persistent state for those services.<br></div><d=
iv><br></div><div>At first, I thought that I could just define static uids =
and gids for these system accounts by adding corresponding user-account and=
 user-group entries. But this doesn&#39;t work: rather than changing how th=
e system accounts are defined for these services, it results in /etc files =
with duplicate entries. (See <a href=3D"https://issues.guix.gnu.org/45570">=
https://issues.guix.gnu.org/45570</a> for details.)</div><div><br></div><di=
v><br></div></div>

--00000000000016c49b05b7c6a996--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Jason Conroy <conjaroy@HIDDEN>
Subject: bug#45571: Acknowledgement (Support stable uids and gids for
 system accounts in a container)
Message-ID: <handler.45571.B.160943875717476.ack <at> debbugs.gnu.org>
References: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
X-Gnu-PR-Message: ack 45571
X-Gnu-PR-Package: guix
Reply-To: 45571 <at> debbugs.gnu.org
Date: Thu, 31 Dec 2020 18:20:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 45571 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
45571: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D45571
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#45571: Support stable uids and gids for all accounts
Resent-From: Danny Milosavljevic <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 01 Jan 2021 14:49:01 +0000
Resent-Message-ID: <handler.45571.B45571.160951251512808 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Jason Conroy <conjaroy@HIDDEN>
Date: Fri, 1 Jan 2021 15:47:28 +0100
From: Danny Milosavljevic <dannym@HIDDEN>
Message-ID: <20210101154504.28a18674@HIDDEN>
In-Reply-To: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
References: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/Z/k7LrfZ2VSyz7UEzumfASL";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--Sig_/Z/k7LrfZ2VSyz7UEzumfASL
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi,

I agree that user ids and group ids should be made stable, even in general.

I, too, have been bitten by this.  (So would everyone else if Guix touched
existing UNIX accounts in general)

The right way to make them stable is for Guix ot default each uid to the ha=
sh
of the user name.

That said, we'd want to leave free some range of the integer uids for the u=
sual
suspects (yp, samba) to allocate domain users there.

The place to change is gnu/system/accounts.scm.  It would need to be changed
to do something similar for the "uid" field that it already does for the
"home-directory" field.

According to the source code of "useradd" in the package "shadow", it uses
the following range to use for automatic uid assignment:

Range starts at SYS_UID_MIN (default 1) for system user account uids, and s=
tops
at SYS_UID_MAX (default (UID_MIN - 1)).
=20
For non-system user account uids, it starts at UID_MIN (default 1000) and
stops at 60000 (UID_MAX).

See /etc/login.defs for the configured values.

Note that Linux has no problem using 32 bit uids.

If we want to make it possible for Guix to distinguish system from non-syst=
em
accounts by having different uid ranges for each, "system?" in the
<user-account> record would need to be moved to the front.
Then, in order to be backward compatible, custom procedures/macros
"make-user-account" and "user-account" would need to be provided with the
parameters in the previous order.

Should not be difficult to do--as always, the main work is in agreeing what
should be done, and in testing it after it's done.  The actual change is li=
ke
10 lines of source code.

(An easier workaround would be to make the uid mandatory, with the default
being failure.  But that would be the "punting" solution)

--Sig_/Z/k7LrfZ2VSyz7UEzumfASL
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vNgAACgkQ5xo1VCww
uqWm/Qf7BKjeacyamWrwQD+Jcs9/iRyRbQKhRYks2uG7PbLGVsLs8j0Vv0cLGKVu
IVp/22wuhs0gbwNul3lAHOaYIO1EuawaOwmIGlFt0SywSbzGfMPjPUpfVKwKsOLC
rzFAQcaZgWiwOz2urPhJEONm47q6uKGCuHLqGoV58ABEFS5r/RhV/xWlSBPva+dD
EX/nslH1SJB2/LHZV0UfwXD8yDOYmygYFiPDoInYf9rEZJ9DBX+jEjZtyI3i8Kzw
hjWhTk7YFxcSAi0HaRRYmzVJDy99EiW/TAW4C4ThVmVws+6jP//+xdVVilYgbwey
i9V78V86uC3y9uQ3oH3R3CJdmscKZQ==
=FyvA
-----END PGP SIGNATURE-----

--Sig_/Z/k7LrfZ2VSyz7UEzumfASL--

Message sent to bug-guix@HIDDEN:

Subject: bug#45571: Support stable uids and gids for all accounts
References: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
Resent-From: Leo Prikler <leo.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 01 Jan 2021 16:22:02 +0000
Resent-Message-ID: <handler.45571.B45571.160951806625714 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: dannym@HIDDEN
Cc: 45571 <at> debbugs.gnu.org
Message-ID: <dfa026bb208f02d2e6e99c13b109bce911ffe368.camel@HIDDEN>
From: Leo Prikler <leo.prikler@HIDDEN>
Date: Fri, 01 Jan 2021 17:20:58 +0100
In-Reply-To: 20210101154504.28a18674@HIDDEN
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hello Danny,

I don't think changing the way UIDs are allocated by default is a good
solution as that will break many running installations on real
hardware, that default to those.  A better solution would be to make
user accounts and groups explicit configuration wherever account-
service-type is used, so that it's possible to override them if needed.

Regards,
Leo

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#45571: Support stable uids and gids for all accounts
Resent-From: Jason Conroy <conjaroy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 01 Jan 2021 16:28:01 +0000
Resent-Message-ID: <handler.45571.B45571.160951842126254 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 45571
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Danny Milosavljevic <dannym@HIDDEN>, 45571 <at> debbugs.gnu.org
Received: via spool by 45571-submit <at> debbugs.gnu.org id=B45571.160951842126254
          (code B ref 45571); Fri, 01 Jan 2021 16:28:01 +0000
Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 16:27:01 +0000
Received: from localhost ([127.0.0.1]:34606 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kvNGX-0006pH-1I
	for submit <at> debbugs.gnu.org; Fri, 01 Jan 2021 11:27:01 -0500
Received: from mail-ej1-f43.google.com ([209.85.218.43]:40392)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <conjaroy@HIDDEN>) id 1kvNGV-0006p5-Tb
 for 45571 <at> debbugs.gnu.org; Fri, 01 Jan 2021 11:27:00 -0500
Received: by mail-ej1-f43.google.com with SMTP id x16so28396172ejj.7
 for <45571 <at> debbugs.gnu.org>; Fri, 01 Jan 2021 08:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=JcTq9N6sfK7nT3UeXtxAV7VLssPEyZiyVruacZv63nM=;
 b=e3z2QbdvccjVf3V6076uZS4S1g0JcOzDgFsQ6RYaFQbJfaHdXOwR/j2dBr6YnSw5Pk
 8H/CBx1GyEToctY+yYvOgf2qH/gX4iEv3OXMIxhO07UewJ1dt7KrvPmQVJQ2Y3jLd14V
 eSRRuKKntPGjue11XG4VjW5mYm+lbdQ+zuGpcSUDIoYn0Y8x28OwhnjkgnmecYXuqiVN
 9azHdkU4HCyxE7PkPpXE4oFrzrWNpGrQPrW1fiiG9jEkNZmetdpwFF3lDEFTVmCuA7+o
 ia4AksLxoTAdyz23KF/K9g7jfPfu0Squb8y7pcEVVYC9RfYCFcH9XvOTwaLLgSVDIHLN
 E22A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=JcTq9N6sfK7nT3UeXtxAV7VLssPEyZiyVruacZv63nM=;
 b=eBfUHALkK/IVjqSjZcj1Q1vqmwxsY7EvLejSn5LGtVG/ZVRuGd0et9mqxfB17s4E8e
 WPgHCoEUtq0BK3HBosl+iJvQIm9ZAGrpbudkrR0yBnoBsf1UHdHwYjUZUz80BhRT7poK
 yEJahaolOG516HY+DiFvvPuTWodCFq2hzk6yHt1ji6cXJRzb9BslODVrFysBMVWDH1Fd
 nJUAWubcuJm8PT8cP2hb4TC9Akk6z9DrZclnRH70XwPyRcqVva8MRGjfwKF8RoGJEg8V
 YR9OOW8ajBx/+AcbHpgF71gbRgQTx0b0JJkAx+bFPQQMKuAdO0MAfZZmP4lBDKN8c4ru
 DyOA==
X-Gm-Message-State: AOAM533UI4KTWnk3v8PqGP7lgpdaBKMj0mvJ+CClDQiqpg0Zpn1rVfyo
 TaNBfSRKCnshr3fJpTQ6d5T/ry3tBuRSPSIVJ/A=
X-Google-Smtp-Source: ABdhPJwuVvA/xkB2ZuTlhtAB24F6Y40IYOrcXP5+7w2vwTGl2Z5N337nnNY1ywyyxnNnAbFInlHZSiMEkqV87yEskL8=
X-Received: by 2002:a17:907:435c:: with SMTP id
 oc20mr58801238ejb.286.1609518414115; 
 Fri, 01 Jan 2021 08:26:54 -0800 (PST)
MIME-Version: 1.0
References: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
 <20210101154504.28a18674@HIDDEN>
In-Reply-To: <20210101154504.28a18674@HIDDEN>
From: Jason Conroy <conjaroy@HIDDEN>
Date: Fri, 1 Jan 2021 11:26:18 -0500
Message-ID: <CABWzUjXg6rZhniTdruFA=TZQhjRR+Ft5CSYqVNrS-PrdD6rxyA@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000005535ac05b7d9359b"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000005535ac05b7d9359b
Content-Type: text/plain; charset="UTF-8"

Hi Danny,

Your idea has a definite elegance to it. :) I did not realize that Linux
supported 32-bit UIDs out-of-the-box. Still, I wonder if this could
introduce support challenges for packages that incorrectly assume UIDs are
16 bits wide, since they traditionally were that way in UNIX, and since
other Linux distros still seem to prefer small UIDs in their packaging. By
comparison, my earlier idea of declaring static UIDs/GIDs in the
operating-system is decidedly less elegant, but it avoids this particular
risk. Can we be confident that this class of integer width bugs is
extremely rare?

On Fri, Jan 1, 2021 at 9:49 AM Danny Milosavljevic <dannym@HIDDEN>
wrote:

> Hi,
>
> I agree that user ids and group ids should be made stable, even in general.
>
> I, too, have been bitten by this.  (So would everyone else if Guix touched
> existing UNIX accounts in general)
>
> The right way to make them stable is for Guix ot default each uid to the
> hash
> of the user name.
>
> That said, we'd want to leave free some range of the integer uids for the
> usual
> suspects (yp, samba) to allocate domain users there.
>
> The place to change is gnu/system/accounts.scm.  It would need to be
> changed
> to do something similar for the "uid" field that it already does for the
> "home-directory" field.
>
> According to the source code of "useradd" in the package "shadow", it uses
> the following range to use for automatic uid assignment:
>
> Range starts at SYS_UID_MIN (default 1) for system user account uids, and
> stops
> at SYS_UID_MAX (default (UID_MIN - 1)).
>
> For non-system user account uids, it starts at UID_MIN (default 1000) and
> stops at 60000 (UID_MAX).
>
> See /etc/login.defs for the configured values.
>
> Note that Linux has no problem using 32 bit uids.
>
> If we want to make it possible for Guix to distinguish system from
> non-system
> accounts by having different uid ranges for each, "system?" in the
> <user-account> record would need to be moved to the front.
> Then, in order to be backward compatible, custom procedures/macros
> "make-user-account" and "user-account" would need to be provided with the
> parameters in the previous order.
>
> Should not be difficult to do--as always, the main work is in agreeing what
> should be done, and in testing it after it's done.  The actual change is
> like
> 10 lines of source code.
>
> (An easier workaround would be to make the uid mandatory, with the default
> being failure.  But that would be the "punting" solution)
>

--0000000000005535ac05b7d9359b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Danny, <br></div><div><br></div><div>Your idea has=
 a definite elegance to it. :) I did not realize that Linux supported 32-bi=
t UIDs out-of-the-box. Still, I wonder if this could introduce support chal=
lenges for packages that incorrectly assume UIDs are 16 bits wide, since th=
ey traditionally were that way in UNIX, and since other Linux distros still=
 seem to prefer small UIDs in their packaging. By comparison, my earlier id=
ea of declaring static UIDs/GIDs in the operating-system is decidedly less =
elegant, but it avoids this particular risk. Can we be confident that this =
class of integer width bugs is extremely rare?<br></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 1, 2021=
 at 9:49 AM Danny Milosavljevic &lt;<a href=3D"mailto:dannym@HIDDEN=
g">dannym@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hi,<br>
<br>
I agree that user ids and group ids should be made stable, even in general.=
<br>
<br>
I, too, have been bitten by this.=C2=A0 (So would everyone else if Guix tou=
ched<br>
existing UNIX accounts in general)<br>
<br>
The right way to make them stable is for Guix ot default each uid to the ha=
sh<br>
of the user name.<br>
<br>
That said, we&#39;d want to leave free some range of the integer uids for t=
he usual<br>
suspects (yp, samba) to allocate domain users there.<br>
<br>
The place to change is gnu/system/accounts.scm.=C2=A0 It would need to be c=
hanged<br>
to do something similar for the &quot;uid&quot; field that it already does =
for the<br>
&quot;home-directory&quot; field.<br>
<br>
According to the source code of &quot;useradd&quot; in the package &quot;sh=
adow&quot;, it uses<br>
the following range to use for automatic uid assignment:<br>
<br>
Range starts at SYS_UID_MIN (default 1) for system user account uids, and s=
tops<br>
at SYS_UID_MAX (default (UID_MIN - 1)).<br>
<br>
For non-system user account uids, it starts at UID_MIN (default 1000) and<b=
r>
stops at 60000 (UID_MAX).<br>
<br>
See /etc/login.defs for the configured values.<br>
<br>
Note that Linux has no problem using 32 bit uids.<br>
<br>
If we want to make it possible for Guix to distinguish system from non-syst=
em<br>
accounts by having different uid ranges for each, &quot;system?&quot; in th=
e<br>
&lt;user-account&gt; record would need to be moved to the front.<br>
Then, in order to be backward compatible, custom procedures/macros<br>
&quot;make-user-account&quot; and &quot;user-account&quot; would need to be=
 provided with the<br>
parameters in the previous order.<br>
<br>
Should not be difficult to do--as always, the main work is in agreeing what=
<br>
should be done, and in testing it after it&#39;s done.=C2=A0 The actual cha=
nge is like<br>
10 lines of source code.<br>
<br>
(An easier workaround would be to make the uid mandatory, with the default<=
br>
being failure.=C2=A0 But that would be the &quot;punting&quot; solution)<br=
>
</blockquote></div>

--0000000000005535ac05b7d9359b--

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#45571: Support stable uids and gids for all accounts
Resent-From: Danny Milosavljevic <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 01 Jan 2021 17:37:01 +0000
Resent-Message-ID: <handler.45571.B45571.1609522609512 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 45571
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Jason Conroy <conjaroy@HIDDEN>
Cc: 45571 <at> debbugs.gnu.org
Received: via spool by 45571-submit <at> debbugs.gnu.org id=B45571.1609522609512
          (code B ref 45571); Fri, 01 Jan 2021 17:37:01 +0000
Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 17:36:49 +0000
Received: from localhost ([127.0.0.1]:34717 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kvOM5-00008C-0p
	for submit <at> debbugs.gnu.org; Fri, 01 Jan 2021 12:36:49 -0500
Received: from dd26836.kasserver.com ([85.13.145.193]:34420)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dannym@HIDDEN>) id 1kvOM2-000082-NC
 for 45571 <at> debbugs.gnu.org; Fri, 01 Jan 2021 12:36:48 -0500
Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at
 [80.110.127.104])
 by dd26836.kasserver.com (Postfix) with ESMTPSA id E06843363807;
 Fri,  1 Jan 2021 18:36:43 +0100 (CET)
Date: Fri, 1 Jan 2021 18:36:37 +0100
From: Danny Milosavljevic <dannym@HIDDEN>
Message-ID: <20210101183637.6ff62412@HIDDEN>
In-Reply-To: <CABWzUjXg6rZhniTdruFA=TZQhjRR+Ft5CSYqVNrS-PrdD6rxyA@HIDDEN>
References: <CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@HIDDEN>
 <20210101154504.28a18674@HIDDEN>
 <CABWzUjXg6rZhniTdruFA=TZQhjRR+Ft5CSYqVNrS-PrdD6rxyA@HIDDEN>
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_/iIhj5cxIiZ7J/Hc92CzLmLW";
 protocol="application/pgp-signature"; micalg=pgp-sha512
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--Sig_/iIhj5cxIiZ7J/Hc92CzLmLW
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Jason,

>Still, I wonder if this could introduce support challenges for packages th=
at
>incorrectly assume UIDs are 16 bits wide, since they traditionally were th=
at
>way in UNIX,

I don't think that these 16 bit problems are common at all since all the
getuid() syscalls I've ever seen, even in traditional UNIXes, have "int" as
return value--and nowadays that's at least 32 bits; and also because UNIX
configuration is usually in text files, which would read and store the stuff
using "%d".  That said, it's possible that it could happen in some seriously
strange configurations (I doubt it).

> and since other Linux distros still seem to prefer small UIDs in
> their packaging. By comparison, my earlier idea of declaring static UIDs/=
GIDs
> in the operating-system is decidedly less elegant, but it avoids this par=
ticular
> risk.=20

If we did something like that, I would prefer for guix services to just spe=
cify
a fixed UID/GID for each of the entries in gnu/services/*.scm.  We can even
reuse existing system uids and gids that have been statically allocated
already by FreeBSD and Debian and be even uid/gid compatible to those.

For example, change Guix to do (similarly for all Guix services using user
accounts):

diff --git a/gnu/services/monitoring.scm b/gnu/services/monitoring.scm
index 5123a8c441..45d3f4ad17 100644
--- a/gnu/services/monitoring.scm
+++ b/gnu/services/monitoring.scm
@@ -71,6 +71,7 @@
=20
 (define %darkstat-accounts
   (list (user-account
+         (uid 4711)
          (name "darkstat")
          (group "darkstat")
          (system? #t)
@@ -78,6 +79,7 @@
          (home-directory "/var/lib/darkstat")
          (shell (file-append shadow "/sbin/nologin")))
         (user-group
+         (id 4711)
          (name "darkstat")
          (system? #t))))

And other constants for other user names.

Or use hashes.  Whichever.  The point is that the ids are deterministic--not
necessarily that we need to use hashes.  The advantage of using a hash is t=
hat
we don't need a central registry and this problem will be out of our life o=
nce
and for all.

Anyway, as a workaround for your immediate problem, I suggest to preserve
/etc/passwd, /etc/group and /etc/shadow--present entries in those will be
preferred by Guix to even its own configuration.  (I'm not sure whether tha=
t's
currently easy to do with guix system container, however)

--Sig_/iIhj5cxIiZ7J/Hc92CzLmLW
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vXaUACgkQ5xo1VCww
uqV4twf/SE9DMqS+8viTnEak25kEV7V5xCU7eRyiBDqI1XyrXuL55Si03mkCrmbI
gbP0EC7/qR4JDyapRyoAlVif4Z0R9zgVD4jBxDi/8Sz7+mjnvwj1KfMxCIeQhbqg
FcGiO5smE1yQHupNXWkTW04dzqzgl3FP0vQtAcAHht1z3Hc0REHfhNJ/aYu6GbyQ
YdcPh7qBL9gY1B1CY2Ap0pdoFF4pFEDUYCg3lW4VWKwCngmCD+D0mifxevXLAjix
b9Z/lh+4nkQJvzoHssZJLFGHdhsLBXyvR5ok+7bWM0er0z1+ChYoAsVhCOTQVM13
8lSeASGEFMcrt7X5bqL71f6WSwKn8g==
=SB/f
-----END PGP SIGNATURE-----

--Sig_/iIhj5cxIiZ7J/Hc92CzLmLW--

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#45571: Support stable uids and gids for all accounts
Resent-From: Danny Milosavljevic <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 01 Jan 2021 17:51:02 +0000
Resent-Message-ID: <handler.45571.B45571.16095234191793 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 45571
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Leo Prikler <leo.prikler@HIDDEN>
Cc: 45571 <at> debbugs.gnu.org
Received: via spool by 45571-submit <at> debbugs.gnu.org id=B45571.16095234191793
          (code B ref 45571); Fri, 01 Jan 2021 17:51:02 +0000
Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 17:50:19 +0000
Received: from localhost ([127.0.0.1]:34753 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kvOZ9-0000Sr-HD
	for submit <at> debbugs.gnu.org; Fri, 01 Jan 2021 12:50:19 -0500
Received: from dd26836.kasserver.com ([85.13.145.193]:35238)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dannym@HIDDEN>) id 1kvOZ7-0000Se-H0
 for 45571 <at> debbugs.gnu.org; Fri, 01 Jan 2021 12:50:18 -0500
Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at
 [80.110.127.104])
 by dd26836.kasserver.com (Postfix) with ESMTPSA id 17816336521B;
 Fri,  1 Jan 2021 18:50:16 +0100 (CET)
Date: Fri, 1 Jan 2021 18:50:12 +0100
From: Danny Milosavljevic <dannym@HIDDEN>
Message-ID: <20210101184838.21869359@HIDDEN>
In-Reply-To: <dfa026bb208f02d2e6e99c13b109bce911ffe368.camel@HIDDEN>
References: <dfa026bb208f02d2e6e99c13b109bce911ffe368.camel@HIDDEN>
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_/4F9etEZHa5OAgo_R2mI+fjA";
 protocol="application/pgp-signature"; micalg=pgp-sha512
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--Sig_/4F9etEZHa5OAgo_R2mI+fjA
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

On Fri, 01 Jan 2021 17:20:58 +0100
Leo Prikler <leo.prikler@HIDDEN> wrote:

> I don't think changing the way UIDs are allocated by default is a good
> solution as that will break many running installations on real
> hardware, that default to those. =20

(gnu build accounts), allocate-passwd defaults to keep using the uids of
existing /etc/passwd entries.  So running installations on real hardware
will not be affected when we change the defaults--otherwise those
installations on real hardware would already have had big problems regarding
user accounts with the current version of Guix when someone adds a user acc=
ount
(system account or not) to them.  Then, depending on the order of the decla=
red
user-accounts, the uids would have swapped.

>A better solution would be to make
> user accounts and groups explicit configuration wherever account-
> service-type is used, so that it's possible to override them if needed.

They already are explicit.

For example, (gnu services monitoring) has:

>(define %darkstat-accounts
>  (list (user-account
>         (name "darkstat")
>         (group "darkstat")
>         (system? #t)
>         (comment "darkstat daemon user")
>         (home-directory "/var/lib/darkstat")
>         (shell (file-append shadow "/sbin/nologin")))
>        (user-group
>         (name "darkstat")
>         (system? #t))))

and then

>   (extensions
>    (list (service-extension account-service-type
>                             (const %darkstat-accounts))

As you can see, the user and group accounts are already explicit.  What's
more, the uid (and group id) can already be specified right there, and I
argue that it should be specified right there, and that there should be a
stable default if it's not specified.

So to summarize:

(1) This bug is a real problem, and something should be done about it.

(2) The reason it doesn't currently affect Guix system users is because the=
re
is logic preferring existing /etc/passwd, /etc/shadow and /etc/group entries
(which I agree is a good idea).  Doesn't help for guix system container, th=
ough.

Or for NFS network file systems.  Any time you have more than one computer
(even with Guix on it) with a filesystem in the network and regular users,
you have to have consistent uids or have a lot of weird uid maps per comput=
er
that someone has to maintain, or worse, an extra service just mapping them.
Why do that to yourself?

(3) For /etc/shadow, it also makes sense to keep the existing entry (the us=
er
name is the key for the search for it btw) because of the password set.

(4) It makes sense to keep the existing /etc/{passwd,shadow,group} entries =
both
for backward compatibility and also for extensibility of guix with user & g=
roup
accounts guix knows nothing about.

(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.

(6) Since (5) would move the burden to the user, it would be better usabili=
ty
to generate uid and gid in a deterministic manner as a default.

Both (5) and (6) can be done even now without problems because of (2).

--Sig_/4F9etEZHa5OAgo_R2mI+fjA
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vYNQACgkQ5xo1VCww
uqXjIgf/a3oYUVFXIxWvOQuPlfCUIqmNducup/1Ak0xgM7vc5NYdxFfLef1FResi
l3meMnL4ZbmECInGrQ9NicXPuod94wU30wHc20dB3ZvGxgifqvyXaKi8fo+oruEb
e8GVi8jS+MzypsrzF0sGihb0DUHI54TCvFhUZAg3pXeZPgK/9P/5NXbQEhsqnEuU
IbBcufV5YrzI6ngpDERyfIikIblJhhP7EgDiSJd6rcRRTN9bkvuKD97lcDK1RVe2
hioRw/G7ic5EvDJ2gKucaT6YIHQJRXriQ1emLyPSNkuj+9HFGRWM1QydhPhbQMA3
XcJIgPZjHaNLFLG9kQ745EatiTN9nw==
=ZiyK
-----END PGP SIGNATURE-----

--Sig_/4F9etEZHa5OAgo_R2mI+fjA--

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#45571: Support stable uids and gids for all accounts
Resent-From: Leo Prikler <leo.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 01 Jan 2021 18:45:02 +0000
Resent-Message-ID: <handler.45571.B45571.16095266607044 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 45571
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Danny Milosavljevic <dannym@HIDDEN>
Cc: 45571 <at> debbugs.gnu.org
Received: via spool by 45571-submit <at> debbugs.gnu.org id=B45571.16095266607044
          (code B ref 45571); Fri, 01 Jan 2021 18:45:02 +0000
Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 18:44:20 +0000
Received: from localhost ([127.0.0.1]:34842 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kvPPP-0001pX-Ub
	for submit <at> debbugs.gnu.org; Fri, 01 Jan 2021 13:44:20 -0500
Received: from mailrelay.tugraz.at ([129.27.2.202]:17052)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <leo.prikler@HIDDEN>) id 1kvPPM-0001pN-RY
 for 45571 <at> debbugs.gnu.org; Fri, 01 Jan 2021 13:44:18 -0500
Received: from nijino.local (217-149-174-13.nat.highway.telekom.at
 [217.149.174.13])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D6v7d536kz1LBMx;
 Fri,  1 Jan 2021 19:44:13 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D6v7d536kz1LBMx
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1609526653;
 bh=hAk9266j2IogqDV1Tz0Hf4TDTgSRt0SDDWUJ4hQGm4g=;
 h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
 b=tOpCG7KU5BIXDk7CnPynBdML+iTuj6sko6nsCn31vBIftXQwaYn+QJyMf07ASe6In
 8zW+fldjnIGhKqGAbjiJYwcWgSsGYAninh7GxfrZ52ycQKpwGRzHQ54v18Q3coNYWw
 ZR8dBz4nV/yrFfuN0yEIiepu5510cTnzpW1puh2I=
Message-ID: <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@HIDDEN>
From: Leo Prikler <leo.prikler@HIDDEN>
Date: Fri, 01 Jan 2021 19:44:12 +0100
In-Reply-To: <20210101184838.21869359@HIDDEN>
References: <dfa026bb208f02d2e6e99c13b109bce911ffe368.camel@HIDDEN>
 <20210101184838.21869359@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -1.9
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi,

Am Freitag, den 01.01.2021, 18:50 +0100 schrieb Danny Milosavljevic:
> Hello,
> 
> On Fri, 01 Jan 2021 17:20:58 +0100
> Leo Prikler <leo.prikler@HIDDEN> wrote:
> 
> > I don't think changing the way UIDs are allocated by default is a
> > good
> > solution as that will break many running installations on real
> > hardware, that default to those.  
> 
> (gnu build accounts), allocate-passwd defaults to keep using the uids
> of
> existing /etc/passwd entries.  So running installations on real
> hardware
> will not be affected when we change the defaults--otherwise those
> installations on real hardware would already have had big problems
> regarding
> user accounts with the current version of Guix when someone adds a
> user account
> (system account or not) to them.  Then, depending on the order of the
> declared
> user-accounts, the uids would have swapped.
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?

> > A better solution would be to make
> > user accounts and groups explicit configuration wherever account-
> > service-type is used, so that it's possible to override them if
> > needed.
> 
> They already are explicit.
> 
> For example, (gnu services monitoring) has:
> 
> > (define %darkstat-accounts
> >  (list (user-account
> >         (name "darkstat")
> >         (group "darkstat")
> >         (system? #t)
> >         (comment "darkstat daemon user")
> >         (home-directory "/var/lib/darkstat")
> >         (shell (file-append shadow "/sbin/nologin")))
> >        (user-group
> >         (name "darkstat")
> >         (system? #t))))
> 
> and then
> 
> >   (extensions
> >    (list (service-extension account-service-type
> >                             (const %darkstat-accounts))
> 
> As you can see, the user and group accounts are already
> explicit.  What's
> more, the uid (and group id) can already be specified right there,
> and I
> argue that it should be specified right there, and that there should
> be a
> stable default if it's not specified.
How is that explicit?  The % even implies, that it's considered
internal to the definition.  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.

> So to summarize:
> 
> (1) This bug is a real problem, and something should be done about
> it.
Naturally.

> (2) The reason it doesn't currently affect Guix system users is
> because there
> is logic preferring existing /etc/passwd, /etc/shadow and /etc/group
> entries
> (which I agree is a good idea).  Doesn't help for guix system
> container, though.
> 
> Or for NFS network file systems.  Any time you have more than one
> computer
> (even with Guix on it) with a filesystem in the network and regular
> users,
> you have to have consistent uids or have a lot of weird uid maps per
> computer
> that someone has to maintain, or worse, an extra service just mapping
> them.
> Why do that to yourself?
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?
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.

> (3) For /etc/shadow, it also makes sense to keep the existing entry
> (the user
> name is the key for the search for it btw) because of the password
> set.
See above.

> (4) It makes sense to keep the existing /etc/{passwd,shadow,group}
> entries both
> for backward compatibility and also for extensibility of guix with
> user & group
> accounts guix knows nothing about.
Not knowing about such accounts sounds somewhat antithetical to Guix,
but whatever.

> (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.
> 
> (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.
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)?
As far as I understand it, same config.scm + same
/etc/{passwd,group,shadow} => same /etc/{passwd,group,shadow}.

Regards,
Leo

Last modified: Fri, 1 Jan 2021 19:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.