-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Comments
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. |
No it should not be staled. This issue is always happening. Thanks. |
This issue has been automatically marked as not stale anymore due to the recent activity. |
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. |
Hello, Please can someone take this issue under investigation ? Thanks |
This issue has been automatically marked as not stale anymore due to the recent activity. |
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. |
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. |
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 :
And start it :
docker-compose -f /path/to/compose/file -p myproject up -d
Make a second one with :
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) andmy-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 frommyproject_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}).
The text was updated successfully, but these errors were encountered: