8:45 a.m.
On 9/8/20 09:02, Chris Evich wrote:
On 9/8/20 12:48 AM, Chintan from Rebhu wrote:
> The same error is not present when I switch from v1.15.0 to v1.14.4
> of Envoyproxy.
>
> I am out of my wits about this. Please tell me how I should find a
> solution.
>
> We only use Podman in our infrastructure.
Hi,
First off, I don't mean to dismiss the scale of your frustrations or
challenges here. However, this list may not be the appropriate place
for seeking infrastructure support for third-party interoperability
(open-source or closed).
We're really narrowly focused on podman and it's intimately related
container technologies, and improving the state thereof. If you're
looking for end-to-end debugging and help, then a commercial support
option would probably be best.
OTOH, I see you're follow-up mail, which does have some
podman-specific questions we can probably help with. I just want to
be clear up-front, that this list is not an official/commercial means
for overall/general system support.
The SELinux implications of the change are potentially problematic, and
I would love to see the AVCs to understnad what is going on.
Bottom line with SELinux is we are attempting to prevent the container
from modifying anything on the host, in this case it looks like the
container is attempting to modify tty's security permissions/ownershift
with host based labels that are being handed to the container.
If podman was handing the same ttys that are used by the terminal then
the container could cause the terminal to potentially do some bad
things. If Podman is creating the tty's handed into the container, then
it should be setting the SELinux labels on these ttys to be fully
manageable by the container. I am not sure which is truly the case.
I would question an executable needing to modify terminal settings...