supporting core dumps when Envoy has more capabilities

[rgs1]

When Envoy is running inside a container where CAP_NET_BIND_SERVICE isn't available but the Envoy binary itself has this capability (e.g.: via setcap 'cap_net_bind_service=+ep' envoy), core dumps won't happen unless Envoy was launched via a process with the same capabilities [0].

Forcing deployments to use a helper with bind capabilities to launch Envoy isn't great, because the helper would have to be restricted itself otherwise it could be use by others to gain bind privileges.

One potential solution is to have Envoy re-exec itself, since no new capabilities are gained when Envoy re-executes itself.

Would something like this be acceptable?

cc: @mattklein123

[0] See PR_SET_DUMPABLE in https://man7.org/linux/man-pages/man2/prctl.2.html and also https://man7.org/linux/man-pages/man7/capabilities.7.html

[rgs1]

Ok, just had a chat with @martinezjavier about capabilities and prctl, the solution is much simpler than having to re exec: prctl(PR_SET_DUMPABLE, 1); does it.

I'll prepare a draft PR and we can discuss if this has to be behind a command line flag or runtime flag.

[mattklein123]

I don't know much about this stuff, but these seems reasonable to me. I think there was another issue at some point about dropping privileges after starting which seems somewhat related but I can't find that issue right now.

[rgs1]

Ah yes, I think uid --> euid mismatches means the dumpability bit will be unset as well. This should work for that case too.