seccomp: ignore unsupported wait-kill flag probe#5347
Conversation
|
@pacoxu did you also verify this solves the issue on CI somehow? |
There was a problem hiding this comment.
Thanks for the PR! This almost LGTM. If this fixes the issue, I'm fine using this as a quick-fix to release 1.5.1
However, I'd also like to understand how runc is being built in kubernetes CI (not blocking the merge). I guess it is being compiled with an old seccomp headers (< 2.6.0), but run with new headers (>= 2.6.0). Can you confirm this is true?
Signed-off-by: Paco Xu <roollingstone@gmail.com>
This is precisely the situation I aimed to prevent for |
rata
added
the
backport/1.5-todo
lifubang
added
backport/1.5-done
This has nothing to do with the headers (libseccomp-golang provides missing defines). Also, the call is guarded by |
OK this is about headers; the proposed fix is in seccomp/libseccomp-golang#127 |
This was initially reported to kubernetes[1] and fixed in runc[2] by ignoring EINVAL. The original underlying issue though is when libseccomp-golang is compiled against an older version of libseccomp headers, the new flag attributes (such as WAITKILL) are set to 0 instead of a proper value, because for some reason _SCMP_FLTATR_MIN was used (starting from commit 4b17538). As a result, seccomp_attr_set(3) returns EINVAL, as 0 is not a valid attribute value. The fix is to provide the real values of the attributes so even when older headers are used we still have the correct values. NOTE we can't use #ifndef and instead rely on a headers version check because those values are part of an enum. This bug eluded our tests because we always use the same libseccomp for compilation and testing. [1]: kubernetes/kubernetes#140039 [2]: opencontainers/runc#5347 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For some reason, since commit 4b17538 the filter attributes missed from includes were defined to _SCMP_FLTATR_MIN (which is an invalid value) and so, when used, resulted in EINVAL (see [1], [2]). From the first sight it looks like those are to be never used in practice as we have the API level check. Yet, when the libseccomp version used during runtime is newer than the one used during build time, it is quite possible (since GetAPI returned the runtime version). The GetAPI behavior is fixed, but still it makes little sense to have those defines set to an invalid value. Fix to use the correct numbers. [1]: kubernetes/kubernetes#140039 [2]: opencontainers/runc#5347 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For some reason, since commit 4b17538 the filter attributes missed from includes were defined to _SCMP_FLTATR_MIN (which is an invalid value) and so, when used, resulted in EINVAL (see [1], [2]). From the first sight it looks like those are to be never used in practice as we have the API level check. Yet, when the libseccomp version used during runtime is newer than the one used during build time, it is quite possible (since GetAPI returned the runtime version). Fix to use the correct numbers. [1]: kubernetes/kubernetes#140039 [2]: opencontainers/runc#5347 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For some reason, since commit 4b17538 the filter attributes missed from includes were defined to _SCMP_FLTATR_MIN (which is an invalid value) and so, when used, resulted in EINVAL (see [1], [2]). From the first sight it looks like those are to be never used in practice as we have the API level check. Yet, when the libseccomp version used during runtime is newer than the one used during build time, it is quite possible (since GetAPI returned the runtime version). Fix to use the correct numbers. [1]: kubernetes/kubernetes#140039 [2]: opencontainers/runc#5347 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
4 participants
See kubernetes/kubernetes#140039.
The logic here was added in #5172.