flatcar
core doesn't get default entries in /etc/subuid and /etc/subgid except with podman where they are broken
Description and Impact
Core doesn’t get entries in /etc/subuid and /etc/subgid because it isn’t created with them. All other users get entries because they are created by ignition. This breaks rootless containers for core. I believe that ignition directly calls useradd which is why this happens.
When the podman sysext is added there is a workaround added to fix this. It overwrites the first characters in /etc/sub[ug]id after users have been created by ignition. This can leave the file in an unusable state. Further the addition is hard coded to a specific range and doesn’t account for what else ignition may have done. This seems to be caused by this and the following lines
w /etc/subuid - - - - core:1065536:65536
w /etc/subgid - - - - core:1065536:65536
Environment and steps to reproduce
Here are two examples:
Core + 4 Users (default)
butane file:
variant: flatcar
version: 1.1.0
passwd:
users:
- name: core
ssh_authorized_keys:
- ssh-ed25519 ...
- name: one
- name: two
- name: three
- name: four
On the resulting VM:
core@user-test ~ $ cat /etc/subuid
one:100000:65536
two:165536:65536
three:231072:65536
four:296608:65536
core@user-test ~ $ cat /etc/subgid
one:100000:65536
two:165536:65536
three:231072:65536
four:296608:65536
Core + 4 users + podman -docker -containerd
ignition file:
variant: flatcar
version: 1.1.0
passwd:
users:
- name: core
ssh_authorized_keys:
- ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIfFF+O2JFqmW/AYoMitdXJ3C69DKnx+qH6jBCRBpO/V
- name: one
- name: two
- name: three
- name: four
storage:
files:
# Add Podman and configure it
- path: /etc/containers/policy.json
contents:
source: https://raw.githubusercontent.com/containers/podman/main/test/policy.json
- path: /etc/flatcar/enabled-sysext.conf
contents:
inline: |
podman
links:
# Remove docker and containerd
- path: /etc/extensions/docker-flatcar.raw
target: /dev/null
overwrite: true
- path: /etc/extensions/containerd-flatcar.raw
target: /dev/null
overwrite: true
On the resulting VM:
core@user-test ~ $ cat /etc/subuid
core:1065536:65536wo:165536:65536
three:231072:65536
four:296608:65536
core@user-test ~ $ cat /etc/subgid
core:1065536:65536wo:165536:65536
three:231072:65536
four:296608:65536
Expected behavior
Core should always have entries in /etc/subuid and /etc/subgid. Those entries should not be added in a way that could damage the file. Those entries should be in ranges consistent with allowing other users on the system.
Additional information
none
I have tried to trace how core is created, but can't quite grok it. Based on this set of lines I'd thought it was created by ignition before the user provided ignition was run, however that doesn't seem to be the case or we would have entries in /etc/sub[ug]id. Therefore this is likely used in the image building process and "baked" into the resulting image used on first boot before ignition is applied.
To be clear, I know the maintainers know how this works, however, I am including this comment as I think it shows both evidence I did a bit of digging (yeah me!) but also points to a need to expand the boot process overview docs to document what is baked in by default.
Thanks @bexelbie for the issue. We simply removed the subuid/subgid handling from the Podman sysext. This was creating more issues than it solved (and it somehow forces user to run in rootless mode).
From newer releases (>4403), if a user wants to setup those IDs, and it has to be done directly from initial configuration.
