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

[Leo Prikler <leo.prikler@student.tugraz.at>]

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