Open morfikov opened 5 years ago
This kernel module wasn't designed with filesystem name-spacing in mind, as it was started prior to docker becoming popular. You don't see /usr/local/bin/docker-entrypoint.sh
on your filesystem, because that file exists within the namespace of the docker container.
As far as allowing execution of it -- the real fix should be to the container itself. Inside docker or not, proper filesystem owernship and permissions should always be done first. It's the group writable bit on this file that's causing the problem.
Now of course in the world of docker, you have a lot of images which don't conform to proper filesystem security & other things, because people are assuming the docker does sandboxing well enough. In short, you're going to have a lot of problem running docker containers that you didn't craft yourself.
The easiest workaround I can think of is to add an option to disable checking for execution outside of the root namespace (ie; inside docker containers) to prevent collisions between TPE and running docker containers. The containers won't get the TPE protection, but the host still will.
Does that sound like an acceptable solution to you?
I think it should be.
When I start some docker containers I get the following log:
It says, that
/usr/local/bin/docker-entrypoint.sh
is untrusted , but I don't have this file in my system:The file in question is inside of the container:
I tried to add the execs to
tpe.trusted_apps
, but that doesn't work. So how to handle such case like docker?