systemd-userdb Mishandled

[mtalexan]

Bug Report

If any users or groups are defined using the systemd-userdb JSON drop-in files in /usr/lib/userdb, the coreos-assembler is incorrectly generating a user.ign file during image creation that duplicates the settings and causes a failure.

Environment

What operating system is being used to run coreos-assembler? Docker

What operating system is being assembled? Variant of fedora-coreos-config with an extra overlay.d

Is coreos-assembler running in Podman or Docker? Podman

If Podman, is coreos-assembler running privileged or unprivileged? privileged

Expected Behavior

Putting files in /usr/lib/userdb/ should have no effect at all on the ignition file generated for the coreos-assembler output image.

Actual Behavior

A user.ign ignition file is being generated with a passwd section that duplicates the settings from the /usr/lib/userdb of the rootfs during image creation.

Reproduction Steps

1. Add user and group JSON files for systemd-userdb with UID=1000, GID=1000 to the /usr/lib/userdb/ folder via overlay.
2. Build a qcow2 image
3. Attempt to run the qcow2 image in a VM
4. See the dracut emergency shell ignition errors about creating the users/groups

Other Information

[mtalexan]

This seemingly intentional(?) behavior is guaranteed to always fail. Ignition runs from the initramfs, when systemd-userdb isn't available. Resultantly, it can never detect the users specified via JSON file drop in, so it will always trigger the "create" behavior. The only creation behavior defined for Ignition is to write the /etc/passwd and /etc/shadow files in the sysroot directly, which will always be guaranteed to cause a conflict with the systemd-userdb users once the system is booted.

[jlebon]

This should probably be an issue against Ignition instead.

[mtalexan]

This should probably be an issue against Ignition instead.

The issue is that coreos-assembler (or possibly something in rpm-ostree compose or osbuild?) is generating an ignition file it shouldn't. There's no reason I can think of why it would ever be beneficial to list the users already supplied by systemd-userdb in the ignition file as well. If everything works together perfectly, it has no effect at all. If anything doesn't quite match, it causes very hard to trace errors.

I'm not sure what or who thought it would be a good idea to do this automatic scraping and duplication, but to the best of my knowledge it can't possible ever help anything.

So I don't think this is an Ignition problem, it's a problem with whatever tool decided to try and duplicate the user specification into an ignition file.

[jlebon]

OK right sorry, when you say:

Attempt to run the qcow2 image in a VM

You're talking about e.g. cosa run, right?

I think it'd help if you should the full logs of cosa run -c up to the point where it enters the emergency shell.