Re: A corner case of broken reproducibility

[Maxime Devos <maximedevos@telenet.be>]

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

Ludovic Courtès schreef op wo 01-06-2022 om 18:38 [+0200]:
> Things that seem missing here to me:
> 
>    * a mechanism for remembering that an uid is still in use even
> though
>      the user has been removed (previously mentioned solutions: keep
> the
>      uid in /etc/passwd even though it is ‘removed’, or keep a
> separate
>      /etc/passwd-graveyard or such, etc.).  For system accounts and
> user
>      accounts.  Won't help in this particular case but would make
> more
>      general adding/removing user accounts less fragile (avoid 
>      accidental reuse).

How do you know that user “maxime” created today is “the same” as that
“maxime” deleted a while back?  You can’t.

The point above was about remembering that uids (arbitrary unique
numbers) are still in use, and only tangentially about user names (the
/etc/passwd bit).

We can have a mechanism for registering that an uid that hasn't an
associated name anymore but might still be in use somewhere
(by a process or a file) and hence shouldn't be reused automatically,
without having to touch the concept of user names at all.

We don't have to know that they are the same or different (though we
could implement some kind of heuristic that old "foo" is the same as
new "foo" if that's desired), we only need some kind of mechanism to
stop automatically breaking things.

> (gnu build accounts) is stateful in that it makes sure UIDs aren’t
> reused.  (This is roughly the same algorithm as used by Shadow.)

It doesn't?  AFAICT it only takes /etc/passwd and /etc/groups in
account and there was some bug report reusing uids in system accounts
after removing a service (something about tor and gdm?), adding another
service and re-adding the original service or something like that.

> >    * a mechanism for telling Guix ‘I'm renaming the user account,
> > not
> >      creating and removing a new one, so keep the uid’
> 
> Every system generation stands alone though; it’s functional,
> stateless, and all that.  What does “rename” mean in this context?

A declaration in the configuration that in the past the user "bar" has
been named "foo", so if during reconfiguration Guix doesn't find "bar"
in /etc/passwd but it does find "foo", it shouldn't assign a new uid
and remove "foo" or such but rather change "foo:...:THIS-UID:.." entry
to "bar:...:THAT-UID":

(user-account
  (name "foo")
  (old-names '("bar" "baz"))
  (old-home-directories '("/home/bar" "/home/baz")) ; rename the old
/home/bar to /home/foo
  [...])

It's a bit state-y though in the sense that it refers to the previous
system configurations (and it wouldn't interact well with rollbacks
because the old configurations wouldn't have "foo" in old-names), so
some other solutions may be needed!

E.g., here's an alternative solution:

  * Require each user to be given unique identifier (UUID?) that cannot
    be changed (unlike uid or username or home directory).
    Record the UUID in /etc/passwd or such somehow.

    Example:

    + Configuration 1

    (user-account
      (name "foo")
      (uid 1234)
      (persistent-identifier "THE-UUID")
      (home-directory "/home/foo"))

    At first boot, this creates a foo:...:1234:...:THE-UUID entry in
    /etc/passwd as no user with THE-UUID exists yet.  Likewise, it also
    creates /home/foo

    + Configuration 2:

    (user-account
      (name "bar")
      (user 4321)
      (persistent-identifier "THE-UUID")        
      (home-directory "/home/bar"))

    At reconfiguration, Guix notices that THE-UUID already exists, so
    it renames the old home directory /home/foo (listed in
    /etc/passwd) to /home/bar, chowns /home/foo to 4321, and changes
    the passwd entry to use 4321 as uid and "bar" as username

    + Rolling-back to configuration 1: likewise.

A complication however: home directories on external media
that might not even be attached during reconfiguration, or
external media that are read-only.  And not being able to rename the
THE-UUID is a limitation.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]