/tmp directory requires "exec" mode for docker-compose execution

[HaleyACS]

Description of the issue

recent docker-compose version (tested with 1.27.4) requires /tmp to have exec flag set.
Most secured systems have nodev, nosuid, noexec applied to the /tmp directory by default.
It is possible to relocated the tmp directory, but IMHO this is not how it should work.

Context information (for bug reports)

Output of docker-compose version

smurphy@stargate:/home/prodadm$ sudo curl -L https://github.com/docker/compose/releases/download/1.27.4/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   651  100   651    0     0   5612      0 --:--:-- --:--:-- --:--:--  5612
100 11.6M  100 11.6M    0     0  6737k      0  0:00:01  0:00:01 --:--:-- 10.2M
smurphy@stargate:/home/prodadm$ hash -r
smurphy@stargate:/home/prodadm$ docker-compose --version
docker-compose: error while loading shared libraries: libz.so.1: failed to map segment from shared object

Output of docker version

$ docker version
Client: Docker Engine - Community
 Version:           20.10.2
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        2291f61
 Built:             Mon Dec 28 16:17:32 2020
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.2
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8891c58
  Built:            Mon Dec 28 16:15:09 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker-compose config
(Make sure to add the relevant -f and other flags)

Not possible ...

Steps to reproduce the issue

1. install latest docker-compose version
2. execute anything while system is in secured state

Observed result

Will always return a:

$ docker-compose ps
docker-compose: error while loading shared libraries: libz.so.1: failed to map segment from shared object

Expected result

Working docker-compose

Stacktrace / full error message

$ docker-compose ps
docker-compose: error while loading shared libraries: libz.so.1: failed to map segment from shared object

Additional information

OS version / distribution, docker-compose install method, etc.
Wget installation from git repo.
Ubuntu server 18.04.5 LTS

[HaleyACS]

Note - one can circumvent the /tmp directory using:

alias docker-compose="TMPDIR=/var/tmp docker-compose"

but that is not how it is supposed to run IMHO.

[ulyssessouza]

Hello @HaleyACS ! Thanks for the report.
Looking at the logs I just see that libz cannot be found. You can check that by running:

ldd /path/to/docker-compose

If it cannot be found that's another problem... But a system problem and not a docker-compose's issue

[HaleyACS]

That's the point. If I tell docker-compose to use a different TMPDIR=/var/tmp, it works.
So docker-compose does something in /tmp - and if it cannot execute something in there, it fails.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[agmorey]

Aliasing if fine, however, I would like a solution that support multiple users on a shared host. Our environment enforces noexec on /tmp per CIS benchmark and I assume DOD STIGs.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[Nox-404]

Hi,
I do have the same problem...

ldd do finds libz.so.1

Here is a strace:

docker-compose.strace.log

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.