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

[Leo Prikler]

Hi Danny,
Am Samstag, den 02.01.2021, 15:50 +0100 schrieb Danny Milosavljevic:
> [...]
> I agree, if in addition.
> 
> (Or if a registry is undesireable, calculate the uids by user name.
> These are the possibilities.  If hashing user names is too uncommon
> on
> UNIX elsewhere, I say that we have no /usr or /lib, so we are not
> exactly doing
> common things in Guix because they are common--what we do really
> depends on the
> merits)
I don't think hashing has much merit if you have the range of 100-1000
to work with.  Using the full 32 bit integer range also feels like a
hack just to enable hashing, and even then hash functions targeting 32
bit integers are not known to be the most secure in this world.  In
other words, hashing user names into IDs is little more than theatre
and while it can certainly mitigate the underlying issue in *some*
cases, it is not by itself a solution.

> > > From the solutions we do have so far, I believe that making user
> > > accounts an explicit part of service configuration (in what shape
> > > may
> > > still be up for debate), 
> 
> Not everything needs to be user configurable.  You suggest having
> these kinds
> of things especially user-configurable as a work-around for them not
> being
> stable, right?  Or do you want it in general?
I believe there might be a general utility for that if we're not going
to use an existing passwd as oracle.  In that case, you would need a
way of claiming those IDs from the config.scm.

Other than that, I believe you pointed out an NFS example, where it
could also be beneficial to sync up user/system accounts with the IDs
they have on other machines within the network.  Of course, if all
machines within the network use Guix, that point is moot, but there
might be a case when you want to play nice with that one old Debian
server.

> I would like to avoid them here, if only needed for that reason.
> 
> (Also, if they are user-configurable, then it's much easier for uid
> collisions
> to happen than if Guix manages them)
Sure, but either way we'll need a collision checker, will we not?

> So after thinking about it some more, I disagree that that is the
> best option
> for this specific problem.
> 
> In my opinion, the best option here is all of these things:
> 
> (1) To document that you need to seed /etc/passwd (for Docker etc)
> (2) For guix system container to default to the host's /etc/passwd
> and
> (3) For guix system container to add and retain (!) its own
> /etc/passwd for
> accounts only it has (merged together with the host's /etc/passwd for
> ease
> of implementation)
That's also a solution and I think I'd prefer that over spamming IDs
throughout the codebase.

> The suggestions I made before that would obsolete /etc/passwd storage
> got
> watered down to a version where they don't obsolete /etc/passwd
> storage and
> thus I oppose doing them in that form.  It would be making the stuff
> more
> complicated--and now you'd have TWO /etc/passwd:
> 
> * one /etc/template-passwd (for the uid registry)
> (might as well integrate that into guix as a scheme file, though),
> * and one /etc/passwd with the currently created users. 
> 
> This seems to be excessive just for making uids stable.
FWIW I think taking the passwd-seed as a file-like object, that
defaults to using the host's /etc/passwd might work here, but I'm not
completely sure.

> > That seems reasonable to me. As for representation, I think there's
> > value
> > decoupling these settings from a service's own config so that
> > support for
> > custom UIDs/GIDs remains consistent across services.
> 
> Is there a need for using custom service UIDs?
> I think if so, that is independent of this bug report, which asked
> for
> stable UIDs and GIDs.
I agree, the discourse regarding that has been muddled a bit, but since
custom implies stable I don't think this option can be completely
discarded.  Of course, both stability and customization are also given
by a passwd-seed, so if we choose that implementation, other means of
customization might not be needed.

Regards,
Leo