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

[Danny Milosavljevic <dannym@scratchpost.org>]

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

Hello,

On Fri, 01 Jan 2021 17:20:58 +0100
Leo Prikler <leo.prikler@student.tugraz.at> 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.

>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 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?

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

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

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]