Support stable uids and gids for system accounts in a container

Open

Details

6 participants

Arun Isaac
Brendan Tildesley
Jason Conroy
Danny Milosavljevic
Leo Prikler
Ludovic Courtès

Owner: unassigned

Submitted by: Jason Conroy

Severity: normal

Jason Conroy wrote on 31 Dec 2020 19:18

Recipients:(address . bug-guix@gnu.org)

Message-ID:CABWzUjULfU-uvBMB13oS=xD9Jv4u8R6TrDErTKVRbSVfwmUgmQ@mail.gmail.com

If I understand correctly, the container script produced by "guix system
container" will allocate the same uid and gid for a service on each
execution, but only if the corresponding entry in the service list has the
same absolute position as it did before. I.e., if the services are
reordered or if there are additions and removals, it's unlikely that the id
allocations will be the same.

As long as a container's filesystems don't outlive the container itself,
this works fine. But when host filesystems are bind-mounted inside the
container with the --share or --expose options, it's important that each
incarnation of a service uses the same uid and gid, because the bind mounts
might be used to hold persistent state for those services.

At first, I thought that I could just define static uids and gids for these
system accounts by adding corresponding user-account and user-group
entries. But this doesn't work: rather than changing how the system
accounts are defined for these services, it results in /etc files with
duplicate entries. (See https://issues.guix.gnu.org/45570for details.)

Attachment: file

Danny Milosavljevic wrote on 1 Jan 2021 15:47

Support stable uids and gids for all accounts

Recipients:(name . Jason Conroy)(address . conjaroy@gmail.com)

Message-ID:20210101154504.28a18674@scratchpost.org

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)

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vNgAACgkQ5xo1VCww

uqWm/Qf7BKjeacyamWrwQD+Jcs9/iRyRbQKhRYks2uG7PbLGVsLs8j0Vv0cLGKVu

IVp/22wuhs0gbwNul3lAHOaYIO1EuawaOwmIGlFt0SywSbzGfMPjPUpfVKwKsOLC

rzFAQcaZgWiwOz2urPhJEONm47q6uKGCuHLqGoV58ABEFS5r/RhV/xWlSBPva+dD

EX/nslH1SJB2/LHZV0UfwXD8yDOYmygYFiPDoInYf9rEZJ9DBX+jEjZtyI3i8Kzw

hjWhTk7YFxcSAi0HaRRYmzVJDy99EiW/TAW4C4ThVmVws+6jP//+xdVVilYgbwey

i9V78V86uC3y9uQ3oH3R3CJdmscKZQ==

=FyvA

-----END PGP SIGNATURE-----

Leo Prikler wrote on 1 Jan 2021 17:20

Recipients:(address . dannym@scratchpost.org)(address . 45571@debbugs.gnu.org)

Message-ID:dfa026bb208f02d2e6e99c13b109bce911ffe368.camel@student.tugraz.at

Hello Danny,

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

Regards,

Leo

Jason Conroy wrote on 1 Jan 2021 17:26

Recipients:

Message-ID:CABWzUjXg6rZhniTdruFA=TZQhjRR+Ft5CSYqVNrS-PrdD6rxyA@mail.gmail.com

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:

Toggle quote (50 lines)> 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: file

Danny Milosavljevic wrote on 1 Jan 2021 18:36

Recipients:(name . Jason Conroy)(address . conjaroy@gmail.com)(address . 45571@debbugs.gnu.org)

Message-ID:20210101183637.6ff62412@scratchpost.org

Hi Jason,

Toggle quote (4 lines)

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

I don't think that these 16 bit problems are common at all since all the
getuid() syscalls I've ever seen, even in traditional UNIXes, have "int" as
return value--and nowadays that's at least 32 bits; and also because UNIX
configuration is usually in text files, which would read and store the stuff
using "%d".  That said, it's possible that it could happen in some seriously
strange configurations (I doubt it).

Toggle quote (5 lines)

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

If we did something like that, I would prefer for guix services to just specify

a fixed UID/GID for each of the entries in gnu/services/*.scm. We can even

reuse existing system uids and gids that have been statically allocated

already by FreeBSD and Debian and be even uid/gid compatible to those.

For example, change Guix to do (similarly for all Guix services using user

accounts):

Toggle diff (31 lines)diff --git a/gnu/services/monitoring.scm b/gnu/services/monitoring.scm
index 5123a8c441..45d3f4ad17 100644
--- a/gnu/services/monitoring.scm
+++ b/gnu/services/monitoring.scm
@@ -71,6 +71,7 @@
 
 (define %darkstat-accounts
   (list (user-account
+         (uid 4711)
          (name "darkstat")
          (group "darkstat")
          (system? #t)
@@ -78,6 +79,7 @@
          (home-directory "/var/lib/darkstat")
          (shell (file-append shadow "/sbin/nologin")))
         (user-group
+         (id 4711)
          (name "darkstat")
          (system? #t))))

And other constants for other user names.

Or use hashes.  Whichever.  The point is that the ids are deterministic--not
necessarily that we need to use hashes.  The advantage of using a hash is that
we don't need a central registry and this problem will be out of our life once
and for all.

Anyway, as a workaround for your immediate problem, I suggest to preserve
/etc/passwd, /etc/group and /etc/shadow--present entries in those will be
preferred by Guix to even its own configuration.  (I'm not sure whether that's
currently easy to do with guix system container, however)

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vXaUACgkQ5xo1VCww

uqV4twf/SE9DMqS+8viTnEak25kEV7V5xCU7eRyiBDqI1XyrXuL55Si03mkCrmbI

gbP0EC7/qR4JDyapRyoAlVif4Z0R9zgVD4jBxDi/8Sz7+mjnvwj1KfMxCIeQhbqg

FcGiO5smE1yQHupNXWkTW04dzqzgl3FP0vQtAcAHht1z3Hc0REHfhNJ/aYu6GbyQ

YdcPh7qBL9gY1B1CY2Ap0pdoFF4pFEDUYCg3lW4VWKwCngmCD+D0mifxevXLAjix

b9Z/lh+4nkQJvzoHssZJLFGHdhsLBXyvR5ok+7bWM0er0z1+ChYoAsVhCOTQVM13

8lSeASGEFMcrt7X5bqL71f6WSwKn8g==

=SB/f

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 1 Jan 2021 18:50

Recipients:(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 45571@debbugs.gnu.org)

Message-ID:20210101184838.21869359@scratchpost.org

Hello,

On Fri, 01 Jan 2021 17:20:58 +0100

Leo Prikler <leo.prikler@student.tugraz.at> wrote:

Toggle quote (4 lines)

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

Toggle quote (4 lines)

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

Toggle quote (12 lines)>(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

Toggle quote (4 lines)

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

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vYNQACgkQ5xo1VCww

uqXjIgf/a3oYUVFXIxWvOQuPlfCUIqmNducup/1Ak0xgM7vc5NYdxFfLef1FResi

l3meMnL4ZbmECInGrQ9NicXPuod94wU30wHc20dB3ZvGxgifqvyXaKi8fo+oruEb

e8GVi8jS+MzypsrzF0sGihb0DUHI54TCvFhUZAg3pXeZPgK/9P/5NXbQEhsqnEuU

IbBcufV5YrzI6ngpDERyfIikIblJhhP7EgDiSJd6rcRRTN9bkvuKD97lcDK1RVe2

hioRw/G7ic5EvDJ2gKucaT6YIHQJRXriQ1emLyPSNkuj+9HFGRWM1QydhPhbQMA3

XcJIgPZjHaNLFLG9kQ745EatiTN9nw==

=ZiyK

-----END PGP SIGNATURE-----

Leo Prikler wrote on 1 Jan 2021 19:44

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 45571@debbugs.gnu.org)

Message-ID:2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at

Hi,

Am Freitag, den 01.01.2021, 18:50 +0100 schrieb Danny Milosavljevic:

Toggle quote (22 lines)> 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?

Toggle quote (34 lines)> > 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.

Toggle quote (4 lines)

> So to summarize:

> (1) This bug is a real problem, and something should be done about

> it.

Naturally.

Toggle quote (16 lines)> (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.

Toggle quote (4 lines)

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

Toggle quote (5 lines)> (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.

Toggle quote (7 lines)> (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

Danny Milosavljevic wrote on 1 Jan 2021 21:22

Recipients:(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)

Message-ID:20210101212242.00252cac@scratchpost.org

Hi Leo,

On Fri, 01 Jan 2021 19:44:12 +0100

Leo Prikler <leo.prikler@student.tugraz.at> wrote:

Toggle quote (5 lines)

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

Considering the goal of Guix, it's weird that with Guix, one needs to

store&restore /etc/passwd at all. It's state, but not very useful one.

I mean that's how it is right now--but it's still weird.

With /etc/shadow maybe there's a slightly better case, but note that the key

to find stuff in /etc/shadow can't be the uid--the uid isn't even in there!

Toggle quote (3 lines)

> How is that explicit? The % even implies, that it's considered

> internal to the definition.

Explicit means that the user-account record is initialized right there (every

time account-service-type is extended), by a literal.

And it is. You can see it plain as day in the guix git repo where

account-service-type is used in gnu/services/ .

Implicit would be if some code would generate this <user-account> record

on-the-fly, usually leaving stuff hard to change by the maintainer.

'(user-account (name "x") ...)' is about as explicit as it gets for a record.

The "%" in the name of the binding changes nothing in the literal value.

And it indeed is possible to add (uid 4711) in the literal and it will work

just fine.

Toggle quote (5 lines)

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

Oh, you want internal service users to be USER-configurable. Indeed that is

also what Jason suggested in the initial mail.

But I think that that would put undue burden on each user and is really just

a workaround.

I would really like to caution against us doing a "whack a mole" development

approach, where workarounds like that are introduced to work around bugs

without understanding the underlying causes. So I disagree that having

internal service users be user-configurable is a good idea.

Toggle quote (4 lines)

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

Sure, but that's a last resort. Better is to eliminate state if possible.

Toggle quote (4 lines)

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

It depends on what it is used for, really.

Toggle quote (11 lines)

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

It generates uids using a counter, so it depends on what order

user-accounts are created in by Guix, which depends on the order the user

specifies services in /etc/config.scm and on the order to user accounts

are specified in gnu/services/ by guix maintainers. Then the service

executable (potentially) goes on to create files using those uids.

That means that if you remove or reorder service references in /etc/config.scm,

the uids "want" to change. The only reason they don't change is because the

logic prefers the existing /etc/passwd's uids--a stopgap measure at the last

second to prevent total chaos.

Does any of this sound good to you?

I mean, strictly speaking, it's better than the alternative--but that's a low

bar.

Better would be a making the uid field mandatory and/or generating each uid

from the respective name.

Toggle quote (3 lines)

> As far as I understand it, same config.scm + same

> /etc/{passwd,group,shadow} => same /etc/{passwd,group,shadow}.

That is the intention of (gnu system shadow), I think.  I can't say whether
that's the case in practice now or not.  It certainly was not the case a few
years ago where I did run into the same problem (a necessary condition for
the problem to manifest is that the services change--but my /etc/config.scm
services forms have been stable for a long time now, and Guix upstream also
doesn't change service definitions a lot anymore.  So who knows?).

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/vhJIACgkQ5xo1VCww

uqXjHAgAihpWdLfb4CmXKF0tamt5EkLtW+QXf8gX8vgn74mV6Qj8OwE2G3ZkNsOp

xNR994Ri8W2AOdYOGPlxzEr84hCSZtoiseXeIimCayq2uYINkNnSWvvkHTI6+Xce

GJ7oMDKtQYFAd6rAMRQ1BtBSpnRg9H9zdtnYryxgsDeQd/U+TceVia3/jLn1XfDP

/NuegKSLRwl5QHLIyTk7OMnl+3cXcFCmLx8hbCBus0oq1ufe33nv0K2q5iwKF/js

GrBFekj59ALgSDgsUkRekgcXKwIFTr297Jgav2DhiwBGFced64Yrvbn/ToRq3MDj

w7gz1qOc2jR2ZBpWIMhqsnvUr0Nkmw==

=VfF5

-----END PGP SIGNATURE-----

Leo Prikler wrote on 2 Jan 2021 01:25

Recipients:(address . 45571@debbugs.gnu.org)

Message-ID:90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at

Forgot to CC the ML.

Attachment: file

Danny Milosavljevic wrote on 2 Jan 2021 02:30

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

Recipients:(address . 45571@debbugs.gnu.org)

Message-ID:20210102023020.3e4186d3@scratchpost.org