In Podman or Docker: Permission denied on SELinux machines

[rrichardson]

Permissions issues when running in Podman or Containerd (DockerCE)

Description: When starting envoy in podman or docker (as a UID other than 0)

chown: changing ownership of '/dev/stdout': Permission denied
chown: changing ownership of '/dev/stderr': Permission denied

Presumably it's complaining about this line : https://github.com/envoyproxy/envoy/blob/main/ci/docker-entrypoint.sh#L26

Even if you run as root, SELinux takes exception to a container changing ownership of stdout and stderr.

I haven't found a more elegant workaround than adding this flag in podman:

--security-opt label=disable 

That's a bit of a blunt hammer. There is probably a more precise approach.

I think on non-root podman with cgroupsv2, the chown /dev/std* approach is probably not needed at all, because podman will give the container its very own FDs that pretend to be in, out and err. Maybe in this script we should check the ownership before attempting to change them?

Repro steps:

1. On a recent Linux machine with SELinux enabled (I was working on FCOS 33)
   run:

podman run \
  --name=envoy \
  --hostname=envoy \
  -e ENVOY_UID=1000 \
  -e ENVOY_GID=1000 \
  --user root \
  --security-opt label=disable \
  -p [2600:aba:9d6:baba:f0c0:52ee::]:6443:6443 \
  -v /var/lib/envoy/config/:/config \
  -v /var/lib/envoy/cluster:/cluster \
  docker.io/envoyproxy/envoy:v1.17-latest

[phlax]

Maybe in this script we should check the ownership before attempting to change them?

this seems reasonable, do you want to PR this ?

[phlax]

the other possible improvment here is to check that the user is root and/or is able to chown

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[phlax]

@rrichardson this should be resolved in #15115 can you confirm

[rrichardson]

I'll take a look today or tomorrow. Thanks.

…

On Tue, Mar 2, 2021 at 8:02 PM phlax ***@***.***> wrote: @rrichardson <https://github.com/rrichardson> this should be resolved in #15115 <#15115> can you confirm — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14787 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6KC5L6WHVB2GZY444F63TBWYFHANCNFSM4WNMUYKQ> .

[rrichardson]

@phlax - Using the latest envoyproxy/envoy-dev image, I have verified that the non-root podman execution works correctly.
My invocation looked like:

podman run -it --name envoy --rm -v /var/envoy:/config envoyproxy/envoy-dev:latest -c /config/config.yaml

Running as a non-privileged user (that owns the /var/envoy directory, it was able to run, write to stdout/stderr and load the config.

[phlax]

brilliant - shall we close this ticket ?

[AkhilRaja]

@rrichardson @phlax I still get this issue when I deploy this to cloud run on Google cloud. Any workarounds for me ? Stuck on this for a long time now :( Thanks in advance