fs: Add read_container_root() and copy metadata from /usr -> /

[cgwalters]

OCI container layer tars often don't include a root directory entry, and when they do, container runtimes (Podman, Docker) ignore it and use hardcoded defaults. We had some attempt to handle this with our "stat root" stuff but that only handled mtime - i.e. not permissions or other metadata.

Since the contents of / are ill defined, let's just default to defining them based on /usr since I am not aware of anyone who cares for those to be different (except for the selinux label but we handle that already).

Add new APIs to handle this:

• copy_root_metadata_from_usr(): copies mode, uid, gid, mtime, xattrs from /usr to root directory for deterministic metadata

• read_container_root(): convenience wrapper that calls read_filesystem() then copy_root_metadata_from_usr()

Remove the incomplete have_root_stat/ensure_root_stat() mechanism which only handled mtime. Callers should now explicitly use the new helpers.

Update cfsctl commands (compute-id, create-image, create-dumpfile) to use read_container_root() by default. Add --no-propagate-usr-to-root flag to use raw read_filesystem() for testing.

Assisted-by: OpenCode (Opus 4.5)

[allisonkarlitskaya]

Didn't look at the code but this definitely requires an update to https://github.com/containers/composefs-rs/blob/main/doc/oci.md

[cgwalters]

Thanks, sorry I forgot about that. I've now ensured that's cross-referenced more strongly in the code too.

I added a followup commit here to make even more clear that the "processing OCI layers" is the weird case; from a dumpfile we construct the fs with the root stat metadata that we know is there from the start.

---

That said...I was thinking about this more and realized we still have at least one other big issue in this area that's representative: Right now if SELinux is enabled at build time, we'll pick up the security.selinux xattrs like container_t etc when operating on a mounted root. When targeting a SELinux host, that's fine as that gets overwritten. But if one is targeting a non-SELinux host (a valid use case), then right now we just leak the build-time xattrs into the target (see early return in selabel()) which certainly breaks reproducibility.

More generally I think there are also corner cases where host-side xattrs can visibly leak into the container runtime just because of how overlayfs works. This one relates to containers/storage#1608 (comment) pretty strongly.

I guess for now, the simplest fix might be:

• Fix the transform_for_boot logic to remove all security.selinux xattrs if we don't find a policy in the target root
• Otherwise, only accept an allowlist for xattrs desired from mounted roots, and the default would just be security.capability

[cgwalters]

Added another change to take a much stronger stance around xattrs.

[cgwalters]

Now on /run we could also error out instead of emptying it. We could also try to allow it, but it would make working around the other podman bug a lot more annoying; I think we'd always have to make mount points in / which is too ugly to live.

I don't have a really strong opinion on erroring versus emptying, the main reason I chose emptying is just because we already were doing that for /sysroot and /boot.

[cgwalters]

From live chat: a TODO is to expose configurability for this on the CLI in case anyone wants to allowlist other xattrs for $reasons.

[jeckersb]

👍 LGTM, we went over this in moderate detail in a live chat

[jeckersb]

@allisonkarlitskaya this needs signoff on your requested update to oci.md

Retracting -1