all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: 45571@debbugs.gnu.org
Subject: bug#45571: Support stable uids and gids for all accounts
Date: Fri, 01 Jan 2021 19:44:12 +0100	[thread overview]
Message-ID: <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> (raw)
In-Reply-To: <20210101184838.21869359@scratchpost.org>

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





  reply	other threads:[~2021-01-01 18:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at>
2020-12-31 18:18 ` bug#45571: Support stable uids and gids for system accounts in a container Jason Conroy
2021-01-01 14:47   ` bug#45571: Support stable uids and gids for all accounts Danny Milosavljevic
2021-01-01 16:26     ` Jason Conroy
2021-01-01 17:36       ` Danny Milosavljevic
2021-01-01 16:20   ` Leo Prikler
2021-01-01 17:50     ` Danny Milosavljevic
2021-01-01 18:44       ` Leo Prikler [this message]
2021-01-01 20:22         ` Danny Milosavljevic
2021-01-02  0:25   ` bug#45571: Fwd: " Leo Prikler
2021-01-02  1:40     ` Danny Milosavljevic
2021-01-02  3:10       ` Leo Prikler
2021-01-02 14:02         ` Jason Conroy
2021-01-02 14:29           ` Leo Prikler
2021-01-02 14:52             ` Jason Conroy
2021-01-02 15:35               ` Leo Prikler
2021-01-02 15:58                 ` Jason Conroy
2021-01-02 14:50           ` Danny Milosavljevic
2021-01-02 15:03             ` Jason Conroy
2021-01-02 15:18             ` Leo Prikler
2021-01-02  1:30   ` Danny Milosavljevic
2021-04-07  7:13   ` bug#45571: Support stable uids and gids for system accounts in a container Brendan Tildesley via Bug reports for GNU Guix
2021-06-10  6:02     ` Arun Isaac
2021-01-02 15:04 ` bug#45571: Support stable uids and gids for all accounts Danny Milosavljevic
2021-01-02 15:25   ` Leo Prikler
2021-01-06 10:03   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=45571@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.