ostree-ext: Keep CAP_DAC_READ_SEARCH when passing auth via fd

[gursewak1997]

When running under systemd, ostree-ext drops privileges to 'nobody' with setpriv --bounding-set -all. However, skopeo needs to re-open auth file descriptors at /proc/self/fd/N, which requires CAP_DAC_READ_SEARCH.

Fix by conditionally keeping this capability when auth_data is present: setpriv --bounding-set -all,+dac_read_search

This fixes Anaconda installations with authenticated registries while maintaining security (still runs as unprivileged user).

[Johan-Liebert1]

Looks good. Though, I wonder if we can have skopeo consume the inherited fd instead of reopening it

[cgwalters]

Honestly my inclination now is to entirely drop this isolation. We actually never ported it over to composefs-rs either and the fact that it only triggers when run under a systemd unit cuts our test coverage.

I think the core concept still makes sense, but ultimately if we move to doing "podman pull" or equivalent anyways (ref #20 ) then the code is totally dead.

[gursewak1997]

Honestly my inclination now is to entirely drop this isolation

Do you think we can keep this fix as a short-term solution until the podman pull or equivalent migration or should I remove the isolation feature entirely?

[gursewak1997]

Looks good. Though, I wonder if we can have skopeo consume the inherited fd instead of reopening it

Pretty valid but I think the issue is in how containers-image-proxy (Go side) currently works; it re-opens /proc/self/fd/N instead of using the fd directly. That would require changes in the containers/image codebase.
The fix in here was minimal and might makes sense if we are looking to drop this entirely in future.

[cgwalters]

Do you think we can keep this fix as a short-term solution until the podman pull or equivalent migration or should I remove the isolation feature entirely?

But did you test it? I could believe this works, but this is kind of subtle - it's actually not normal to have an unprivileged user with CAP_DAC_OVERRIDE...

To verify this works, we'd need to setup a pull from a registry with an auth setup from a systemd unit, which...we should totally have, but would require some infrastructure work.

The testing situation is why I would argue to just remove it entirely.

[gursewak1997]

But did you test it?

Yes, I tested it in a bootc VM with systemd-sysext overlaying the fixed binary, INVOCATION_ID set, and /etc/ostree/auth.json present. bootc upgrade --check succeeded and contacted the registry (got "No changes in..." response), confirming CAP_DAC_READ_SEARCH allows skopeo to re-open the fd.

That said, you're absolutely right about the testing infrastructure gap and my test was manual and one-off.

I will close this and put up a new PR to remove this.

PR: #2307