Follow symlink for --device argument. #20684
Conversation
|
Should we have tests for this? |
|
@thaJeztah Sure let me update the pull request. |
|
@thaJeztah Just added the tests. Please let me know if you see any other issues. |
|
Code looks good. It is certainly lucky that it was decided that Any volume that got mounted twice by the same image could contain a symlink to an otherwise forbidden device, because the first time the container was launched the symlink would be created, and the second time the container was launched, the symlink would be followed. It might be worth adding a note in the docs that you can no longer safely use |
|
It's still in design review, so we could consider making this behavior optional, e.g. Add an extra option ( |
|
I don't think that there are many cases where the security flaw could happen, but the following one comes to mind, which I know exists in the wild: The reason why people do this is in order to get the Perhaps there really should be a |
|
LGTM |
| c.Assert(err, checker.IsNil) | ||
|
|
||
| // Create a temporary file, then a symbolic link to the temporary file | ||
| tmpFile := filepath.Join(tmpDir, "zero") |
There was a problem hiding this comment.
Can you explain this?
tmpFile is the same as symZero and then we're writing to it. Can we skip the tmpFile parts and instead use symZero?
There was a problem hiding this comment.
@cpuguy83:
Sorry my bad. That was a bug/typo.
There are two tests:
In the first test is to create a symlink (tmpDir/zero) pointing to /dev/zero, then inside the container do a md5 calculation. This test is to show symlink to a device works.
In the second test, I was meant to create a temporary file, write some data into this temporary file, then create a symlink (tmpDir/file) pointing to the temporary file created. This test was meant to show that symlink to a file (not a device) will not work. (The name of the tmpFile should be something else, not filepath.Join(tmpDir, "zero"))
I will update the pull request shortly.
Fixes: #13840 Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
|
@cpuguy83 Just updated the pull request. Let me know if there are any other issues. |
|
Thanks, LGTM. |
Follow symlink for --device argument.
This fix tries to address the issue raised in moby#22271 where relative symlinks don't work with --device argument. Previously, the symlinks in --device was implemneted (moby#20684) with `os.Readlink()` which does not resolve if the linked target is a relative path. In this fix, `filepath.EvalSymlinks()` has been used which will reolve correctly with relative paths. An additional test case has been added to the existing `TestRunDeviceSymlink` to cover changes in this fix. This fix is related to moby#13840 and moby#20684, moby#22271. This fix fixes moby#22271. Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
This fix tries to address the issue raised in moby#22271 where relative symlinks don't work with --device argument. Previously, the symlinks in --device was implemneted (moby#20684) with `os.Readlink()` which does not resolve if the linked target is a relative path. In this fix, `filepath.EvalSymlinks()` has been used which will reolve correctly with relative paths. An additional test case has been added to the existing `TestRunDeviceSymlink` to cover changes in this fix. backport from: moby#22272 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> Signed-off-by: Yuanhong Peng <pengyuanhong@huawei.com>
Relative symlinks don't work with --device argument This fix tries to address the issue raised in moby#22271 where relative symlinks don't work with --device argument. Previously, the symlinks in --device was implemneted (moby#20684) with `os.Readlink()` which does not resolve if the linked target is a relative path. In this fix, `filepath.EvalSymlinks()` has been used which will reolve correctly with relative paths. An additional test case has been added to the existing `TestRunDeviceSymlink` to cover changes in this fix. backport from: moby#22272 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> Signed-off-by: Yuanhong Peng <pengyuanhong@huawei.com> See merge request docker/docker!348
This pull request fixes issue #13840 where a --device argument fails when the listed device is actually a symlink to a device. It checks to see if the path is a symlink and, if it is, resolves the symlink and continue the operation with the resolved path.
The tests are done in this way. First a symlink is created to link to /dev/zero. Then this symlink is used to map devices in the container. Inside the container a buffer is created and the md5 is calculated:
dd if=/dev/symzero bs=4K count=8 | md5sumThe expected md5 should be
bb7df04e1b0a2570657527a7e108ae23.Fixes: #13840
Signed-off-by: Yong Tang yong.tang.github@outlook.com