If you are are writing the app, I agree with you. Unfortunately in some cases the person/team that wrote the app has been gone for a long time. I've even seen a case where the source code was missing and nobody knew where it was, yet the service had to continue running.
If you're in that boat, there isn't much you can do except work with it.
Agreed. But when copying files to docker and building the image, you will have to take care that files are not written with root ownership in any stage of the build, which would make them inaccessible to the application running as non root.
That's the case I had in mind when writing that quote.
> Agreed. But when copying files to docker and building the image, you will have to take care that files are not written with root ownership in any stage of the build, which would make them inaccessible to the application running as non root.
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.
A completely new user:group namespace is created inside the container. This is, in very large part, what Linux namespaces are for.
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.
If you application needs root to execute, with very few exceptions, it is already wrong.