Where Do Permissions of ‘/tmp’ Folder Inside a Docker Container Inherit From?

centos7dockerlinux

I have a PHP docker container failed to start saying that 'session_start' don't have permissions on /tmp/xxxx file.

I found that the '/tmp' folder's permission is 'drwxr-xr-t'. When I change it to 'drwxrwxrwt', the container works as normal.

I might have done something wrong to my host system to debug another unrelated problem. But I don't remember what I have done and what could causing the problem above.

So I want to know where does the permissions of '/tmp' folder inside a docker container inherited from?

Thanks in advance. 🙂

Best Answer

You should find the answer in the Dockerfile.

Either the base image has already those wrong perms, or the Dockerfile is doing something bad during image build.

In both cases, you can just fix this problem in the Dockerfile, and rebuild a new image.

Related Solutions

Php slowlog causing ptrace error in docker container

I finally figured this out. You need to give the docker container the capability to use ptrace. Simply adding --cap-add SYS_PTRACE to the docker run command fixed this problem for me.

Docker – Why does linux sys fs modification work in plain docker but not under kubernetes

On kubernetes it works a bit differently. Setting privileged: true in a securityContext of a container is not enough to be able to modify any sysctl of such container.

Take a look at this section of the official kubernetes docs that describes Using sysctls in a Kubernetes Cluster. As you can read here:

Sysctls are grouped into safe and unsafe sysctls. In addition to proper namespacing, a safe sysctl must be properly isolated between pods on the same node. This means that setting a safe sysctl for one pod

must not have any influence on any other pod on the node

must not allow to harm the node's health

must not allow to gain CPU or memory resources outside of the resource limits of a pod.

By far, most of the namespaced sysctls are not necessarily considered safe. The following sysctls are supported in the safe set:

kernel.shm_rmid_forced,

net.ipv4.ip_local_port_range,

net.ipv4.tcp_syncookies,

net.ipv4.ping_group_range (since Kubernetes 1.18).

So in short, there are safe and unsafe sysctls. Most of them are considered as unsafe, even many of those which are namespaced. Unsafe sysctls need to be additionally enabled by the cluster admin on a node-by-node basis:

All safe sysctls are enabled by default.

All unsafe sysctls are disabled by default and must be allowed manually by the cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be scheduled, but will fail to launch.

With the warning above in mind, the cluster admin can allow certain unsafe sysctls for very special situations such as high-performance or real-time application tuning. Unsafe sysctls are enabled on a node-by-node basis with a flag of the kubelet; for example:
kubelet --allowed-unsafe-sysctls \  
'kernel.msg*,net.core.somaxconn' ...

So you cannot simply set any sysctl arbitrarily even from a privileged container running on your kubernetes cluster.

Best Answer

Related Solutions

Php slowlog causing ptrace error in docker container

Docker – Why does linux sys fs modification work in plain docker but not under kubernetes

Related Topic