`skopeo.rs`'s container policy resolving does not follow symlinks

[tulilirockz]

At Zirconium we utilize a pattern from system of using /usr/share/factory to manage /etc and other system directories, one of the uses of that pattern is symlinking /etc/containers/policy.json to a path in /usr so users cannot break their policy verification at update time as easily, and can reset them if necessary. It seems that since commit a2bc817222e7f33147662d0802da0f62246609c7 the handling for the container policy does not resolve symlinks, and instead just opens the symlink file itself, that behavior breaks updates because bootc upgrade doesn't recognize the file, see:

root@taxifolia:/home/tulip# bootc --version
bootc 1.16.4
root@taxifolia:/home/tulip# ln -sf /usr/share/factory/etc/containers/policy.json /etc/containers/policy.json
root@taxifolia:/home/tulip# bootc upgrade
error: Upgrading: Preparing import: Fetching manifest: Resolving containers policy path: No containers policy.json found; checked $CONTAINERS_POLICY_JSON, user config dir, and system paths
root@taxifolia:/home/tulip# rm -f /etc/containers/policy.json
root@taxifolia:/home/tulip# cp -f /usr/share/factory/etc/containers/policy.json /etc/containers/policy.json
root@taxifolia:/home/tulip# bootc upgrade
No changes in ostree-image-signed:docker://ghcr.io/tulilirockz/taxifolia:latest => sha256:bebc994639bd3778d7ec89f9ed9123cc00a6a54e9798c1681b90d43ecd5cb297
No update available.

See:
https://github.com/bootc-dev/bootc/blame/a2bc817222e7f33147662d0802da0f62246609c7/crates/ostree-ext/src/container/skopeo.rs#L85-L96

Related issue in Zirconium:
zirconium-dev/zirconium#354

[Johan-Liebert1]

This seems like an issue with cap-std and absolute symlinks