If you application needs root to execute, with very few exceptions, it is already wrong.
edit: I joke, I love what containers accomplish, and working with Docker has been a joy (:
If you're in that boat, there isn't much you can do except work with it.
That's the case I had in mind when writing that quote.
That's not the case, either. And root inside the container != root outside the container. A completely new user:group namespace is created inside the container. This is, in very large part, what Linux namespaces are for.
Further, you can certainly have a root-owned file accessible to non-root users, via chmod bits.
There are only a handful of excuses, ever, to run a privileged container. If you're not 100% sure, then it is not one of those excuses.
No. root inside is root outside (if you can get outside). The behavior you describe only applies if you enable user namespace remapping, which docker doesn’t by default.
As a result, the test needs to be run using sudo to work correctly. The test environment is containerized, so there is a Dockerfile, but as the article mentioned the user in the container should not be root. Is there any plausible way around this? Updating the image is not under my control, and changing the copy code is also riskier than I would like.
Since this is in the context of CI, the threat is lower than live production, but still....
On the other hand, changing the docker user to non root might introduce some failure scenarios (eg file ownership) which might lead to other problems like availability incidents.
Security should start with threat modelling, and taking a risk-based approach. You can spend hours fearing that someone might break out of the Docker virtual machine through a zero day, instead of using that time to fix much more likely and plausible threat scenarios. Pick your battles.