Paths under /var/run ignored

[JonathanRRogers]

Actual behavior
Directories and files created under /var/run do not exist in created image.

Expected behavior
All directories and files created in Dockerfile should exist in created image.

To Reproduce
Create directory /var/run/test in Dockerfile. Observe that /var/run/test doesn't exist in resulting image.

Additional Information

• Dockerfile
  FROM debian
  RUN mkdir -p /var/run/test

[varditn]

@JonathanRRogers I was facing the same problem with building postgres image from Debian and noticed that since /var/run is a pointer to /run, if I do "RUN mkdir -p /run/test", then I find the folder under /run/test on the image.

But I still believe that the problem with /var/run needs to be solved as it does raise a need for a workaround on some installation like in the case of Postgresql.

[JonathanRRogers]

@JonathanRRogers I was facing the same problem with building postgres image from Debian and noticed that since /var/run is a pointer to /run, if I do "RUN mkdir -p /run/test", then I find the folder under /run/test on the image.

The above workaround works on Debian, but not CentOS, since /run and /var/run are distinct directories on CentOS.

[hainesbg]

This also seems to prevent the successful building of things like this: https://docs.docker.com/engine/examples/running_ssh_service/

[JedBartlett]

I'm not sure this is related, but I'm finding that, when building using Jenkins on a Kubernetes cluster, /var/run is being mounted into the image being produced. I start with a very minimal custom base-image and install packages, which includes installing a package called base-files which creates /var/run as a symlink to ../run (/run).

But when I run this on my Jenkins build server, I get the error:

Collected errors:
 * check_data_file_clashes: Package base-files wants to install file /var/run
	But that path is currently a directory

Looking into it further, I see that k8s is automounting /var/run/secrets as part of the pod definition, and kaniko is respecting that.

I was able to get my builds to work by adding automountServiceAccountToken: false to my pod spec in the Jenkinsfile, which stopped the /var/run/secrets from getting mounted automagically when building the image. Mounting secrets through explicitly for the credentials for pushing the image in kaniko continues to work.

[llech]

Is there any known workaround except modifying application so that it doesn't use /var/run ?

[cvgw]

Investigating this issue I found an additional problem. As detailed here on many systems bash does not function correctly for this image. I am unable to create a directory at any path or even run the image with CMD /bin/sh. I believe this to be due to the fact that RUN commands are called using /bin/sh by kaniko. In the centos image this is linked to /bin/bash which fails without the correct capabilities. The image also fails to build using docker build

I did not see the above issue using busybox for example.

cmd: /bin/sh
args: [-c mkdir /foo]
error building image: error building stage: waiting for process to exit: signal: segmentation fault

[cvgw]

I am unable to reproduce this issue. Using the image specified originally centos:centos6 results in a different error. Using busybox or ubuntu:18.04 does not repro the error. User error, made some mistake. The issue is also repro'd on busybox and ubunutu:18.04

[JonathanRRogers]

Investigating this issue I found an additional problem. As detailed here on many systems bash does not function correctly for this image. I am unable to create a directory at any path or even run the image with CMD /bin/sh. I believe this to be due to the fact that RUN commands are called using /bin/sh by kaniko. In the centos image this is linked to /bin/bash which fails without the correct capabilities. The image also fails to build using docker build

I did not see the above issue using busybox for example.

cmd: /bin/sh
args: [-c mkdir /foo]
error building image: error building stage: waiting for process to exit: signal: segmentation fault

What system are you using? I am able to run "docker run --rm -it centos:centos6 bash" on both Ubuntu 18.04.3 LTS (kernel 5.1.0-050100-generic) and Fedora 30 (kernel 5.2.16-200.fc30.x86_64). Under "A note about vsyscall" on https://hub.docker.com/_/centos, it explains how to work around the problem. In any case, system call mapping is unrelated to the problem described in this issue.

[JonathanRRogers]

I am unable to reproduce this issue. Using the image specified originally centos:centos6 results in a different error. Using busybox or ubuntu:18.04 does not repro the error.

Whatever problems you have with centos:centos6 aren't relevant to this issue. I have changed the example Dockerfile to use "debian" instead of "centos:centos6". One could likely use any base image with a "mkdir" command and the problem would be the same.

[cvgw]

I apparently made an error earlier; I now am able to repro the issue with debian, busybox, and ubuntu:18.04

[JonathanRRogers]

I obviously made an error earlier; I now am able to repro the issue with debian, busybox, and ubuntu:18.04

Thanks.

[tejal29]

I think we need to support a feature flag to override whitelists.
some users use /var/run dir which is whitelisted.

[diclophis]

Is it recommended to use /var/run as the target directory for mounting SSH private keys required for building a given image? related: #707