Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug/Security] Wrong volume mounted if only a dash differs in project name. #6904

Closed
Yivan opened this issue Sep 20, 2019 · 8 comments
Closed
Labels

Comments

@Yivan
Copy link

Yivan commented Sep 20, 2019

Description of the issue

When a stack is up and volume are created with a project name (option -p of docker-compose up) having a dash in the name (ex: my-project), it seems docker/docker-compose try to find if a volume prefixed with the project name without a dash exist already (in this exemple: myproject) and if he found one he use it instead creating the volume with dash.

Context information (for bug reports)

Seems to affect a large scope of versions

Seen on : docker-compose version 1.22.0, build f46880f, on Debian 9 stable
Docker version:
Client:
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:48:46 2018
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:16:44 2018
OS/Arch: linux/amd64
Experimental: false

And seen on : docker-compose version 1.24.1, build 4667896, on Debian 10 stable
Client: Docker Engine - Community
Version: 19.03.1
API version: 1.40
Go version: go1.12.5
Git commit: 74b1e89
Built: Thu Jul 25 21:21:24 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 19.03.1
API version: 1.40 (minimum version 1.12)
Go version: go1.12.5
Git commit: 74b1e89
Built: Thu Jul 25 21:19:56 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.6
GitCommit: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
runc:
Version: 1.0.0-rc8
GitCommit: 425e105d5a03fabd737a126ad93d62a9eeede87f
docker-init:
Version: 0.18.0
GitCommit: fec3683

There is no specific configuration of docker or docker-compose, they are native/classic install and use.

Steps to reproduce the issue

Create and up a first stack with :

  myservicename:
    ...
    volumes:
      - "myvolume:/mydatas"

And start it : docker-compose -f /path/to/compose/file -p myproject up -d

Make a second one with :

  myservicename:
    ...
    volumes:
      - "myvolume:/mydatas"

And start it : docker-compose -f /path/to/this/other/compose/file -p my-project up -d

Note the difference in project name : myproject (for the first started) and my-project (for the second one started). The started order is important. If it is played in the other order there is no problem.

Observed result

Inspect the second started service (on my-project) with docker inspect ... and you will see that volume are mounted from myproject_myvolume.

Expected result

It should be my-project_myvolume.

Stacktrace / full error message

No error message, but it messed our multi project stack as volume from another stack was used (just a dash differs in the project name, exactly like the provided exemple).

Additional information

I think it is a serious problem, as IT CAN LEADS TO SECURITY PROBLEM which can be silent, thinking the right container is mounted.

For now, as tempory fix, we post fixe the volume name (myvolume-${projectname}).

@stale
Copy link

stale bot commented Mar 18, 2020

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 stale bot added the stale label Mar 18, 2020
@Yivan
Copy link
Author

Yivan commented Mar 18, 2020

No it should not be staled. This issue is always happening.
Could someone of the docker compose team handle it please ?

Thanks.
Best regards.

@stale
Copy link

stale bot commented Mar 18, 2020

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

@stale stale bot removed the stale label Mar 18, 2020
@stale
Copy link

stale bot commented Sep 14, 2020

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 stale bot added the stale label Sep 14, 2020
@Yivan
Copy link
Author

Yivan commented Sep 15, 2020

Hello,

Please can someone take this issue under investigation ?

Thanks

@stale
Copy link

stale bot commented Sep 15, 2020

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

@stale stale bot removed the stale label Sep 15, 2020
@stale
Copy link

stale bot commented Mar 19, 2021

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 stale bot added the stale label Mar 19, 2021
@Yivan
Copy link
Author

Yivan commented Apr 2, 2021

You can close it, I will open a new one with more step to step description as this problem always occurs and I never received any response.
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant