-
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
Fix runc run "permission denied" when rootless #3753
Conversation
ab28e5c
to
10c0299
Compare
Go 1.20.2 seems released |
Reworked to not re-introduced #3520. Description updated. |
@opencontainers/runc-maintainers PTAL (this needs to be merged then backported to 1.1, and since it is a regression in 1.1.4 I want to fix it in time for 1.1.5). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Go 1.20.2 has an important fix to an issue described in [1]. Switch from using Go 1.19 from Dockerfile, which is used for release binaries and some CI. [1] golang/go#58624 Signed-off-by: Kir Kolyshkin <[email protected]>
Since commit 957d97b was made to fix issue [7], a few things happened: - a similar functionality appeared in go 1.20 [1], so the issue mentioned in the comment (being removed) is no longer true; - a bug in runc was found [2], which also affects go [3]; - the bug was fixed in go 1.21 [4] and 1.20.2 [5]; - a similar fix was made to x/sys/unix.Faccessat [6]. The essense of [2] is, even if a (non-root) user that the container is run as does not have execute permission bit set for the executable, it should still work in case runc has the CAP_DAC_OVERRIDE capability set. To fix this [2] without reintroducing the older bug [7]: - drop own Eaccess implementation; - use the one from x/sys/unix for Go 1.19 (depends on [6]); - do not use anything when Go 1.20+ is used. NOTE it is virtually impossible to fix the bug [2] when Go 1.20 or Go 1.20.1 is used because of [3]. A test case is added by a separate commit. Fixes: opencontainers#3715. [1] https://go-review.googlesource.com/c/go/+/414824 [2] opencontainers#3715 [3] https://go.dev/issue/58552 [4] https://go-review.googlesource.com/c/go/+/468735 [5] https://go-review.googlesource.com/c/go/+/469956 [6] https://go-review.googlesource.com/c/sys/+/468877 [7] opencontainers#3520 Signed-off-by: Kir Kolyshkin <[email protected]>
This is a test case for issue reported as opencontainers#3715. In short, even if a (non-root) user that the container is run as does not have execute permission bit set for the executable, it should still work in case runc has the CAP_DAC_OVERRIDE capability set. Note that since the upstream golang is also broken (see [1]), this test will fail for Go 1.20 and 1.20.1 (fix is in Go 1.20.2 as per [2]). [1] https://go.dev/issue/58552 [2] https://go-review.googlesource.com/c/go/+/469956 Signed-off-by: Kir Kolyshkin <[email protected]>
@AkihiroSuda @thaJeztah addressed your review comments, PTAAL. |
1.1 backport: #3817 |
Fixes: #3715
Since PR #3522 (commit 957d97b) was made to fix issue #3520,
a few things happened:
mentioned in the comment (being removed) is no longer true;
The essense of the bug #3715 is, even if a (non-root) user that the container is
run as does not have execute permission bit set for the executable, it
should still work in case runc has the CAP_DAC_OVERRIDE capability set.
To fix #3715 without reintroducing the older bug [7]:
Add a test case to make sure we won't regress.
NOTE it is virtually impossible to fix the bug [2] when Go 1.20 or Go
1.20.1 is used because of [3].
[1] https://go-review.googlesource.com/c/go/+/414824
[2] #3715
[3] https://go.dev/issue/58552
[4] https://go-review.googlesource.com/c/go/+/468735
[5] https://go-review.googlesource.com/c/go/+/469956
[6] https://go-review.googlesource.com/c/sys/+/468877
[7] #3520