[SECURITY] Transversal data access unallowed can occurs silently.

[Yivan]

Description of the issue

Mounting volume can lead a compose stack to access to another compose stack volume, totally silently to the docker administrator. this can lead to accessing to data not allowed for the other stack.

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.28.6, build 5db8d86f
docker-py version: 4.4.4
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

Output of docker version

Client: Docker Engine - Community
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:17:50 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:15:47 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

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

services:
  myservice:
    command: tail -f /dev/null
    image: alpine
    volumes:
    - myvolume:/mydatas:rw
version: '3.7'
volumes:
  myvolume: {}

Steps to reproduce the issue

Order is very important here, myproject should be started before my-project.

1. docker-compose -f compose.yml -p myproject up -d
2. docker exec myproject_myservice_1 touch /mydatas/secret.txt
3. docker-compose -f compose.yml -p my-project up -d
4. docker exec my-project_myservice_2 ls /mydatas
   Secret file is visible by the second project!

Observed result

We can only see myproject_myvolume which is used by both stack.
The same volume is mounted on both stack. my-project has access to the file created for myproject.
my-project use volume myproject_myvolume, but it should be my-project_myvolume which should have been created.

If the stack my-project is runned first my-project_myvolume is well created.

How to check:

1. docker-compose -f compose.yml -p my-project down
2. docker-compose -f compose.yml -p myproject down
3. docker volume rm myproject_myvolume
4. docker-compose -f compose.yml -p my-project up -d
5. docker volume ls
   We can see my-project_myvolume has been created, here the name is good.

Expected result

It is esxpect that myproject_myvolume and my-project_myvolume are created when i first start the stack myproject and after the stack my-project. Behavious and volume name must not differ depending order of runned composer up commands.

Stacktrace / full error message

N/A

Additional information

I already created some times ago an issue to report the problem but it never get attention (#6904), so I closed this one, hoping this new one will be studied.
I hope it could be fixed as it leads to security concern and strange behaviour in case projet name differs from only a dash and the one without dash is started first.

For pratical use case, we encounter serious problem with project having just a name like "myproject" and the other one "my-project" and the volume was database, leading to the project "my-prject" to use the "myproject" database... pretty hard bug. Hopefully it was in testing environment, but for production environment it could be desastrous.

A malicious user could use this tricky behaviour to access data of another stack.

Tested on Debian buster, official repositories, all up to date, including docker and docker compose.

Thanks!

[Yivan]

Hello,

Any news on this please ?
I wrote the process to recreate it, should be great it is fixed, I don't understand why this is issue is not examined.

Best regards.

[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.