-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
tmpfs and symlink resolution #2683
Comments
Reproduced with bare runc.
{
"destination": "/conf/stack",
"type": "tmpfs",
"source": "tmpfs",
"options": [
"noexec",
"nosuid",
"nodev",
"rprivate"
]
} $ cd rootfs
$ mkdir -p /real/conf
$ ln -s /real/conf conf
$ ls -l conf
lrwxrwxrwx. 1 kir kir 10 Dec 9 18:31 conf -> /real/conf
$ cd ..
$ runc run -d xxx
WARN[0000] unable to terminate initProcess error="exit status 1"
ERRO[0000] container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: rootfs_linux.go:60: mounting "tmpfs" to rootfs at "/conf/stack" caused: mkdir /home/kir/go/src/github.com/opencontainers/runc/tst/rootfs/conf: file exists This is caused by the fact that the symlink is broken in the host context, so MkdirAll is called: runc/libcontainer/rootfs_linux.go Lines 305 to 313 in 544048b
... runc/libcontainer/rootfs_linux.go Lines 340 to 346 in 544048b
To fix, we need to have @zhangyoufu a workaround would be to use a relative symlink in your image, i.e. -/conf -> /quay-registry/conf
+/conf -> quay-registry/conf |
Now, this can be fixed, but I am not sure if it is possible to do so without introducing any new and interesting attack vectors similar to say #2197. Looking. |
In case a tmpfs mount path contains absolute symlinks, runc errors out because those symlinks are resolved in the host (rather than container) filesystem scope. The fix is similar to that for bind mounts -- resolve the destination in container rootfs scope using securejoin, and use the resolved path. A simple integration test case is added to prevent future regressions. Fixes opencontainers#2683. Signed-off-by: Kir Kolyshkin <[email protected]>
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers#2683 Signed-off-by: Kir Kolyshkin <[email protected]>
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers#2683 Signed-off-by: Kir Kolyshkin <[email protected]>
In case a tmpfs mount path contains absolute symlinks, runc errors out because those symlinks are resolved in the host (rather than container) filesystem scope. The fix is similar to that for bind mounts -- resolve the destination in container rootfs scope using securejoin, and use the resolved path. A simple integration test case is added to prevent future regressions. Fixes opencontainers/runc#2683. Signed-off-by: Kir Kolyshkin <[email protected]>
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers/runc#2683 Signed-off-by: Kir Kolyshkin <[email protected]>
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers/runc#2683 Signed-off-by: Kir Kolyshkin <[email protected]>
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers#2683 Signed-off-by: Kir Kolyshkin <[email protected]>
In case a tmpfs mount path contains absolute symlinks, runc errors out because those symlinks are resolved in the host (rather than container) filesystem scope. The fix is similar to that for bind mounts -- resolve the destination in container rootfs scope using securejoin, and use the resolved path. A simple integration test case is added to prevent future regressions. Fixes opencontainers#2683. Signed-off-by: Kir Kolyshkin <[email protected]>
In case a tmpfs mount path contains absolute symlinks, runc errors out because those symlinks are resolved in the host (rather than container) filesystem scope. The fix is similar to that for bind mounts -- resolve the destination in container rootfs scope using securejoin, and use the resolved path. A simple integration test case is added to prevent future regressions. Fixes opencontainers/runc#2683. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry-picked from 637f82d6)
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers/runc#2683 Signed-off-by: Kir Kolyshkin <[email protected]> (cherry-picked from d7df3018)
In case a tmpfs mount path contains absolute symlinks, runc errors out because those symlinks are resolved in the host (rather than container) filesystem scope. The fix is similar to that for bind mounts -- resolve the destination in container rootfs scope using securejoin, and use the resolved path. A simple integration test case is added to prevent future regressions. Fixes opencontainers/runc#2683. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry-picked from 637f82d6)
While working on a test case for [1], I got the following warning: > level=warning msg="unable to terminate initProcess" error="exit status 1" Obviously, the warning is bogus since the initProcess is terminated. This is happening because terminate() can return errors from either Kill() or Wait(), and the latter returns an error if the process has not finished successfully (i.e. exit status is not 0 or it was killed). Check for a particular error type and filter out those errors. [1] opencontainers/runc#2683 Signed-off-by: Kir Kolyshkin <[email protected]> (cherry-picked from d7df3018)
/conf
is a symlink pointing to/quay-registry/conf
, which confuses--tmpfs
.Of course I can pass resolved path
/quay-registry/conf/stack
to--tmpfs
as a workaround. However, this produces an unnamed volume for the original path/conf/stack
, which is unwanted.The text was updated successfully, but these errors were encountered: