bug#45571: Support stable uids and gids for all accounts

[Jason Conroy <conjaroy@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3066 bytes --]