Support systemd-style drop-ins for containers-policy.json

[jbtrystram]

Users can specify their own policy.json file under $HOME/.config/containers/ but if one want to modify the policy system-wide, /etc/containers/policy.json needs to be modified.

Any change done there may be overwritten by subsequent updates. It would be great to support drop-ins in a systemd fashion, e.g :

# /etc/containers/policy.d/10-quay-fedora.json
{
   "transports": {
       "docker" : {
            "quay.io/fedora": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora"
                }
            ]
     }
}

Since this is JSON this could be merged into the existing policy.json fairly easily.

[Luap99]

Well that request comes just in time, ref containers/podman#27657 (comment)

So far I was leaning not to support drop-ins but if there is demand that I guess it makes sense to add support for it. Though it certainly means careful checks for how to actual deal with conflicts.

cc @mtrmac

[jbtrystram]

Though it certainly means careful checks for how to actual deal with conflicts.

I would lean towards a simple "what is defined last wins" , but reading the conversation you linked that would not be good. Not sure why TBH

[mtrmac]

Any change done there may be overwritten by subsequent updates.

That’s not how distributions’ packages are supposed to work with config files. I realize that there’s nuance to this, and things don’t always go to plan, but blindly replacing users’ /etc by default values is not a safe practice and not something software reading from /etc can fix after that happens.

And especially because things don’t always go to plan, I’m very worried about any feature set that allows conflicting policies. I’d much prefer to ask users to resolve conflicts manually, in full control of how that happens.

That’s not a strong reason to reject drop-ins with non-conflicting policies, I suppose… but it still adds some risk.