Add openat2 and faccessat2 to default seccomp profile. #41353
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
AkihiroSuda
approved these changes
Aug 14, 2020
Member
|
Oh, you need to edit or re-generate the JSON variant of the profile as well; After this is merged, could you also open a pull request in containerd to update the profile to match? https://github.com/containerd/containerd/tree/master/contrib/seccomp |
Member
|
I wonder if libseccomp needs an update for this; I see only a single occurence of but many occurrences of |
Contributor
Author
|
Thanks, let me take a look. |
follow up to moby#41344 (comment) Signed-off-by: Jintao Zhang <[email protected]>
tao12345666333
force-pushed
the
add-openat2-to-seccomp-profile
branch
from
1c9bad2 to
b8988c8
Compare
Contributor
Author
@thaJeztah it seems like libseccomp has been updated (release/2.4) seccomp/libseccomp@b3206ad |
Contributor
Author
Opened PR containerd/containerd#4481 |
Member
Ah; yes, I see they switched to a different approach for "master" and the 2.5 branch, and now use a csv; seccomp/libseccomp@f5b3166 Master (and 2.5 branch) already had the |
Member
|
Looking at that last link; should we add |
Contributor
Author
|
Yes, I missed it. |
Signed-off-by: Jintao Zhang <[email protected]>
AkihiroSuda
approved these changes
Aug 17, 2020
thaJeztah
changed the title
justincormack
approved these changes
Aug 17, 2020
Member
|
Hmmm
|
Member
|
Ignoring the ppc64le stage, which is unrelated |
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
jhuntwork
added a commit
to jhuntwork/moby
that referenced
this pull request
Mar 10, 2021
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]>
thaJeztah
pushed a commit
to thaJeztah/docker
that referenced
this pull request
Mar 15, 2021
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]> (cherry picked from commit 1600e85) Signed-off-by: Sebastiaan van Stijn <[email protected]>
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 3, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 3, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 7, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 10, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 18, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
This was referenced Apr 26, 2021
nosamad
pushed a commit
to WAGO/docker-engine
that referenced
this pull request
Sep 13, 2021
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]> (cherry picked from commit 1600e85) Signed-off-by: Sebastiaan van Stijn <[email protected]>
nosamad
pushed a commit
to WAGO/docker-engine
that referenced
this pull request
Sep 15, 2021
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]> (cherry picked from commit 1600e85) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
follow up to #41344 (comment)
Note:
openat2()first appeared in Linux 5.6. And Glibc does not provide a wrapper for this system call; call it usingsyscall(2).ref: https://man7.org/linux/man-pages/man2/openat2.2.html