[WIP] composepost: write sysusers.d fragment with base UIDs/GIDs

[lucab]

Work in progress: this still needs some polish, plus we are waiting for https://pagure.io/setup/pull-requests?status=Open&author=lucab.

---

This imports the table of all known static UIDs/GIDs from the setup package
and adds parsing logic for that.
The immediate usage is to synthesize the content of /etc/passwd and /etc/group
skeletons as equivalent sysusers.d configuration.
Later on, this same table may be used to distinguish between static and dynamic
IDs when importing arbitrary packages with system users/groups.

[travier]

Have you considered directly including those sysusers file into the setup RPM?

[cgwalters]

Have you considered directly including those sysusers file into the setup RPM?

Agree, I'm not excited by carrying a copy of that stuff in rpm-ostree. Among other things, it is surely distribution specific and would potentially be problematic for usage of rpm-ostree in e.g. openSUSE or whatever.

The immediate usage is to synthesize the content of /etc/passwd and /etc/group
skeletons as equivalent sysusers.d configuration.

Can't we do that as a postprocessing operation, using what already exists in /etc/passwd as a source of truth?

[travier]

Another suggestion:

• Do the compose with what we have from the RPMs and the results of scriplet runs, without using additional passwd & group files
• Save those passwd & group files for later comparision
• rm /etc/passwd & group
• Do a systemd-sysusers generation
• Figure out what's missing from the new files compared to the old ones and generate sysusers configs

That might be much harder however.

[lucab]

Have you considered directly including those sysusers file into the setup RPM?

Yes, that's likely where it will end up longer-term, see discussion at systemd/systemd#23509.
There is still some misalignment with systemd to solve first, but that's not really a blocker.
It requires upstream setup involvement which didn't happen so far. I'll keep checking how https://pagure.io/setup/pull-requests?status=Open&author=lucab progress.

But the focus of this is not to generate setup sysusers entries (which can be done in many ways, this is just the quickest hack).
The goal is to have a complete list of static IDs, so that (by exclusion) all the other entries that we will encounter can be translated to dynamic sysusers fragments.

[lucab]

The immediate usage is to synthesize the content of /etc/passwd and /etc/group
skeletons as equivalent sysusers.d configuration.

Can't we do that as a postprocessing operation, using what already exists in /etc/passwd as a source of truth?

To my understanding, in the general case rpm-ostree cannot.

The setup package can (and hopefully will, soon) provide its entries as sysusers configuration, because it knows the content of /etc/passwd before any further manipulation. At that point, all the IDs are static and coming from setup.rpm.

As a counter-example for rpm-ostree, in the non-unified core flow it only gets to parse /etc/passwd late at a point when it contains users and groups with crystallized IDs. But those IDs are really a mix of static entries, plus dynamic IDs which may or may not be different across runs.
A similar case can also happen at package layering time, see #3707.

[cgwalters]

But those IDs are really a mix of static entries, plus dynamic IDs which may or may not be different across runs.

OK, yeah I see your point; we've lost the information about whether the allocation is static or dynamic.

But you also touched on another point - in unified core mode, we can intercept calls to useradd which have this information. In non-unified core...well...in theory we still could by splitting the operation into roughly two phases (one which does a minimal root that has useradd, then we temporarily replace it). But this issue may also be a strong reason to pull off the bandaid and stop supporting non-unified core mode.

(Although of course, it's not only unified core versus not, but we simply cannot intercept useradd invocations for build systems (like osbuild) which only use rpm-ostree compose postprocess, and not the full rpm-ostree compose tree)

[lucab]

Another bit for the puzzle: this uidgid table is also shipped by the setup package under /usr/share/doc/setup/uidgid. However that file (and the whole doc hierarchy) are usually pruned out early in the importing process. Also in FCOS we do remove-files: usr/share/doc (and non-unified-core flows likely do the same).

[lucab]

OK, yeah I see your point; we've lost the information about whether the allocation is static or dynamic.

But you also touched on another point - in unified core mode, we can intercept calls to useradd which have this information

Thanks for the feedback, while it won't solve all our problems I think this may be the most interesting direction to explore right now.
I've noted that at #3762 and I'll look into that kind of binary-interception logic.
I'm closing this for now as we weren't happy with the whole approach and with embedding our own uidgid table.