core user isn't added to groups when created via Ignition

[bgilbert]

The core user is only added to groups if the user doesn't exist on first boot:

fedora-coreos-config/fedora-coreos-base.yaml

Line 118 in f08f79e

ExecStart=/usr/bin/sh -c 'if !getent passwd core &>/dev/null; then /usr/sbin/useradd -G wheel,sudo,adm,systemd-journal core; fi'

Thus, if Ignition is used to add an SSH key to the core user, but the Ignition config doesn't explicitly add the user to groups, it will not have sudo access:

passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - "ssh-rsa ..."

The above config works on Container Linux.

cc @ajeddeloh

[bgilbert]

For context, that logic was originally added in 5a0d60e.

Assumptions:

• Ignition will eventually be able to delete users (Add a way to delete users/groups ignition#738).
• FCOS moves to systemd-sysusers generally (Handling of default users/groups fedora-coreos-tracker#155).
• systemd-sysusers will not generally be used to add groups to the core user. This would work but the UX is bad: inhibiting it requires resetting core's group list and masking the sysusers.d fragment so the group is not readded.

Options:

1. Ship the core user in the base image.
   1. The user can be removed via Ignition.
   2. Creation of the user's private group cannot be inhibited. Other user properties, including the home directory and the list of supplementary groups, can be modified by Ignition.
2. Conditionally create the core user (the status quo).
   1. The user can be created via Ignition with any set of properties, including omission of a user group.
   2. If the config intends the user to have some non-default properties but otherwise replicate OS defaults (primarily the group list), it needs to explicitly encode those defaults.
   3. Creation of the user cannot be inhibited entirely.
3. Create the core user in the Ignition base config.
   1. Via Ignition config merging, the user can be created with any set of properties, including omission of a user group, or inhibited entirely.
   2. Ignition would be involved in applying defaults to the base OS image, which is generally not the preferred approach.
4. Create the core user via systemd-sysusers.
   1. systemd-sysusers is not designed for creating non-system users. It doesn't really want to create users outside the system ID range, and doesn't create home directories. The home directory would need to be created via systemd-tmpfiles.
   2. The user can be removed via Ignition, but the systemd-sysusers and systemd-tmpfiles fragments would also need to be masked to prevent the user from coming back.
   3. Creation of the user's private group could not be inhibited. The user's home directory could be changed, but the systemd-tmpfiles fragment would need to be masked to prevent the old one from coming back. Other user properties, including the list of supplementary groups, could be freely modified by Ignition.

On balance, option 3 seems like the one with the best UX and the fewest negative side effects.

cc @cgwalters

[lucab]

@bgilbert thanks for filing this, I hit it earlier but didn't realize what was going on under the hood. As a very-short-term workaround, I think the unit can be split in a conditional useradd and an unconditional usermod, with the ConditionFirstBoot=true at the top protecting further boots.

For the longer-term, I like that option 1 allows us to know and reference the uid/gid when assembling the base OS in a static way. But I don't know if that it a real use-case we will have to handle (that is, having core referenced by some RPMs content).

[bgilbert]

I think either option 1 or option 3 could be implemented now without a lot of effort.

I'd hope that core isn't referenced by RPM content, especially if we want the core user to be optional. @cgwalters, any perspective on that?

[cgwalters]

I can't think of a reason core would be referenced by RPMs.

[dustymabe]

i'm good with whatever you prefer @bgilbert

[ashcrow]

We now see the same issue referenced in coreos/mantle#981 in RHCOS as well.

[jlebon]

On balance, option 3 seems like the one with the best UX and the fewest negative side effects.

I agree. I think it's likely we'll have other such "conditionals" expressed through an overridable base Ignition config (e.g. for /var partition by default support, we may end up using the same strategy).

[bgilbert]

I went with option 3 in #74.