Provide a customization point for policy.json

[hmenke]

Sometimes it is not possible to install podman in the default location, which is in fact a very common scenario on HPC systems. This includes not being able to put anything in the /etc/containers directory, including policy.json.

In this case, the supported alternative is to use ~/.config/containers/policy.json. However, that requires every user to repeat that configuration and also makes it tricky or even impossible to apply centralized changes.

The location of other configuration files can be customized via environment variables (e.g. $CONTAINERS_STORAGE_CONF) or in containers.conf (e.g. seccomp_profile).

Please provide a customization point for signature policies as well.

[Luap99]

policy.json is not being parsed or used in c/common so this would likely be done in c/image instead

cc @mtrmac

[mtrmac]

(Given that we have so many individual config files, which is, in retrospect, not at all great, but here we are) I’m generally unhappy with individual c/image callers adding their own overrides to config file system locations. We’ve had a fair bit of grief with that when Podman added overrides that were missing, or even ~impossible to add, to other tools.

Similarly, library code invisibly consuming environment variables is… a frequent enough compromise, because it is invisible to all the higher layers of the call stack, but that also makes it unmanageable by those layers. E.g. a privileged program might not consider its environment as a whole to be a possible attack mechanism.

There is c/image/v5/pkg/cli/environment to at least try to centralize such things (for callers who even have a CLI), but that’s mostly to codify existing practice. It does not make consuming environment variables any more of a better idea.

---

Also, the situation… seems somewhat self-inflicted? If I read the report above correctly:

• Per-user settings are not appropriate: the cluster owners want centralized control
• The cluster owners have some way to centrally control environment variables. I don’t know what that is, some script in /etc/skel, a PAM module, or something…
• … but they don’t have any way to write to /etc at all (otherwise?)

I don’t see how this technically works or why this has to be that way. But, also, I’m generally HPC-ignorant.

---

If Podman is not being installed in the default location, and none of the hard-coded paths work (containers.conf can be in neither /usr/share nor /etc), aren’t we talking about a custom binary anyway?

In that case the built-in policy.json path can already be overridden, something like -ldflags '-X github.com/containers/image/v5/signature.systemDefaultPolicyPath=$your_path'

[hmenke]

To given some background, HPC is in a rather dire situation here. When one purchases a new HPC system, the manufacturer provides both hardware and software, i.e. changes to the software stack have to go through them (and should better not conflict with how they set stuff up). Furthermore, compute nodes are usually completely diskless, i.e. they boot an image over the network and then run that from RAM. This puts an additional incentive to keep the image small, so usually the entire software stack that's not absolutely necessary for running the operating system lives in, e.g., /soft which is mounted via NFS/GPFS/GlusterFS/... Hence the ridiculous restriction that nothing can go into /etc, /usr, etc.

In that case the built-in policy.json path can already be overridden, something like -ldflags '-X github.com/containers/image/v5/signature.systemDefaultPolicyPath=$your_path'

Thank you for pointing this out. So far I was patching the source code, but this is evidently much more elegant. Now I only have to find out how to propagate then through the podman Makefile.

[mtrmac]

Yes, that’s painful. Compare containers/skopeo#787 .