From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 11:27:01 2021 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 ) id 1kvNGX-0006pH-1I for submit@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 ) id 1kvNGV-0006p5-Tb for 45571@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@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: <20210101154504.28a18674@scratchpost.org> In-Reply-To: <20210101154504.28a18674@scratchpost.org> From: Jason Conroy Date: Fri, 1 Jan 2021 11:26:18 -0500 Message-ID: Subject: Re: bug#45571: Support stable uids and gids for all accounts To: Danny Milosavljevic , 45571@debbugs.gnu.org Content-Type: multipart/alternative; boundary="0000000000005535ac05b7d9359b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45571 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.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 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 > 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
Hi Danny,

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?

On Fri, Jan 1, 2021= at 9:49 AM Danny Milosavljevic <dannym@scratchpost.org> wrote:
Hi,

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

I, too, have been bitten by this.=C2=A0 (So would everyone else if Guix tou= ched
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 t= he usual
suspects (yp, samba) to allocate domain users there.

The place to change is gnu/system/accounts.scm.=C2=A0 It would need to be c= hanged
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 "sh= adow", 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)).

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 th= e
<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.=C2=A0 The actual cha= nge is like
10 lines of source code.

(An easier workaround would be to make the uid mandatory, with the default<= br> being failure.=C2=A0 But that would be the "punting" solution)
--0000000000005535ac05b7d9359b--