containers-policy.json: provide default config in /usr/

[dustymabe]

Disclaimer: I didn't know where to file this issue. The containers-policy.json file is provided by the containers-common RPM. There is also a https://github.com/containers/common repo, but this man page also lives in the https://github.com/containers/image repo. Please transfer this around to the most appropriate location.

It would be nice if there could be a configuration split like most software where system defaults are provided by the OS distributor in /usr/ and then overriden by the user in either /etc/ or $HOME/.config.

For example, for containers.conf the man page reads:

Container engines read the /usr/share/containers/containers.conf, /etc/containers/containers.conf, and /etc/containers/con‐tainers.conf.d/.conf files if they exist. When running in rootless mode, they also read $HOME/.config/containers/containers.conf and $HOME/.config/containers/containers.conf.d/.conf files.

Can we provide a similar structure for containers-policy.json where the configuration provided in /usr/ is sufficient for a working system?

One example where this is a problem is running skopeo on a system that somehow doesn't have a /etc/containers/policy.json. I ran into one such case in https://github.com/osbuild/osbuild/pull/1410 where /usr/ gets mounted in from the "host" but /etc/ doesn't.

[mtrmac]

Thanks for your report.

Structurally, as to “where to file this”, we’ve made a mess of things: see https://github.com/containers/image/issues/1726 .

---

WRT the idea itself, I’m generally wary of adding any variability to signature enforcement. Admittedly there already is a precedent in looking for per-user files, and the /etc vs. /usr thing is a reasonably established pattern…

I ran into one such case in https://github.com/osbuild/osbuild/pull/1410 where /usr/ gets mounted in from the "host" but /etc/ doesn't.

… but I don’t see this as a strong argument; there are infinite ways to create a broken system.

Actually, “the policy file got somehow lost” is exactly a good reason to “fail closed” and not fall back to some other policy. The default policy in /usr would, I think, have to be pretty permissive (maybe restricting repositories where the OS provider ships code, to be signed by keys from that OS provider) — so falling back from a site-wide strict policy to the built-in fairly permissive one could be a problem.

[dustymabe]

maybe restricting repositories where the OS provider ships code, to be signed by keys from that OS provider

That's what we do today. We (the OS provider being Fedora/Red Hat) ships:

    "transports": {
        "docker": {
        "registry.access.redhat.com": [
        {
            "type": "signedBy",
            "keyType": "GPGKeys",
            "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
        }
        ],
        "registry.redhat.io": [
        {
            "type": "signedBy",
            "keyType": "GPGKeys",
            "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
        }
        ]
    },

but we ship it in /etc/ and not /usr/ like we probably should.

I guess there's another argument to make here being that the keys referenced in that config are also in /etc/.

[mtrmac]

Yes, but if that file is “lost” then we don’t fall back to any other policy, we just fail and force the user to provide a policy.

(Admittedly if the user sets up the policy with something valid but not what was intended, there is no way for policy consumers to tell — and I don’t have a strong argument that “forgot to provide a policy” is a more important failure case than “provided the wrong one”. But still, if we can’t do better in some cases, I don’t think that means we should give up on doing better in other cases.)

[dustymabe]

Thanks for the discussion.

[mtrmac]

I very much appreciate the irony that just filing a “also read from /usr” issue without more justification would probably have had a smoother path; and that adding a real-world use case is what triggered my “oh, wait, this is actually good not to do” reaction.

I don’t really know what’s the best path forward here. It’s definitely valuable to have an issue filed, so that the decision can be centralized and tracked.

[rhatdan]

I think we should move the c/i config files to usr and overrride in /etc for consistency, and then users can just blow away /etc/ to get back to default configuration.