[Podman] Re: Logs show permission denied error

On 9/8/20 1:07 AM, Chintan from Rebhu wrote: Hello again, I cannot speak to the implications for Envoyproxy, but can offer some guidance on the specific questions. 1. This disables SELinux labeling on the host-side, for and resources container tries to use (like volume-mounts). It's generally not something we would recommend doing unless you have a very specific and well understood reason. For example, I use this option when I need to volume-mount a clone of the podman source repository from my home-directory, into a container to run some simple checks. Ordinarily this would fail unless I used the :z or :Z options on the mount. However, these are highly undesireable, since it will complicate future host-side manipulations of the files. Disabling SELinux labeling in this specific case isn't a problem, since the container is short-lived, and I can rely on version-control to track any unexpected changes. 2. This one is a lot more tricky to answer, since the issue you referenced has been fixed in crun. I think the answer really depends much more on exactly how your container is being run (and what the contained process(es) are attempting to do specifically). Based on the context of your other mail, it sounds like you're trying to execute some service in a rootless container, and it's attempting to drop privileges through su or runuser. If so, the answer is simple: don't do that :D If you're running rootless, the contained-user appears to contained-processes as root. However this is a lie and a trick. It's really just UID/GID mapped back to your user/group on the host. It doesn't actually have any consequential access beyond the user account, and especially when SELinux labeling is being enforced. If my assumptions are correct, what you likely need to do is NOT use `--security-opt label=disable'. Instead, volume mount from a dedicated directory on the host (outside of $HOME), and use the :Z or :z volume-mount options. Additionally, inside the rootless container, just run your service as "root". Forget about also using a container-user account through systemd, sudo, su, runuser, etc. It's not buying you any additional protections, just drastically and needlessly complicating the environment. Hopefully that helps. [*] This may not be entirely true, would really need someone more SELinux-knowledgeable and more complete runtime details to answer this fully. -- Chris Evich, RHCA III Senior Quality Assurance Engineer If it ain't broke, yain't tryin' hard nough.