summaryrefslogtreecommitdiffstats
path: root/meta/recipes-core/glibc/glibc/faccessat2-perm.patch
diff options
context:
space:
mode:
authorRoss Burton <ross@burtonini.com>2021-02-11 14:46:45 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2021-02-12 23:32:16 +0000
commit0ba0a534a3e32423a3a1a51aeb60f7bd9cbbd822 (patch)
tree3252928c5c33788d58eeaeb7b93c155a4e89e7ef /meta/recipes-core/glibc/glibc/faccessat2-perm.patch
parentf13c22358a91f2792062d04182f06f215a3cf03b (diff)
downloadpoky-0618b0f13aebda262984e2d730b5fd8eefdb53c7.tar.gz
glibc: add workaround for faccessat2 being blocked by seccomp filtersuninative-3.0
Older seccomp-based filters used in container frameworks will block faccessat2 calls as it's a relatively new syscall. This isn't a big problem with glibc <2.33 but 2.33 will call faccessat2 itself, get EPERM, and thenn be confused about what to do as EPERM isn't an expected error code. (From OE-Core rev: 4d6ad6d611834c2648d6bf9791cb8140967e2529) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-core/glibc/glibc/faccessat2-perm.patch')
-rw-r--r--meta/recipes-core/glibc/glibc/faccessat2-perm.patch31
1 files changed, 31 insertions, 0 deletions
diff --git a/meta/recipes-core/glibc/glibc/faccessat2-perm.patch b/meta/recipes-core/glibc/glibc/faccessat2-perm.patch
new file mode 100644
index 0000000000..2ee7110ca1
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/faccessat2-perm.patch
@@ -0,0 +1,31 @@
1Older seccomp-based filters used in container frameworks will block faccessat2
2calls as it's a relatively new syscall. This isn't a big problem with
3glibc <2.33 but 2.33 will call faccessat2 itself, get EPERM, and thenn be confused
4about what to do as EPERM isn't an expected error code.
5
6This manifests itself as mysterious errors, for example a kernel failing to link.
7
8The root cause of bad seccomp filters is mostly fixed (systemd 247, Docker 20.10.0)
9but we can't expect everyone to upgrade, so add a workaound (originally from
10Red Hat) to handle EPERM like ENOSYS and fallback to faccessat().
11
12Upstream-Status: Inappropriate
13Signed-off-by: Ross Burton <ross.burton@arm.com>
14
15diff --git a/sysdeps/unix/sysv/linux/faccessat.c b/sysdeps/unix/sysv/linux/faccessat.c
16index 56cb6dcc8b4d58d3..5de75032bbc93a2c 100644
17--- a/sysdeps/unix/sysv/linux/faccessat.c
18+++ b/sysdeps/unix/sysv/linux/faccessat.c
19@@ -34,7 +34,11 @@ faccessat (int fd, const char *file, int mode, int flag)
20 #if __ASSUME_FACCESSAT2
21 return ret;
22 #else
23- if (ret == 0 || errno != ENOSYS)
24+ /* Fedora-specific workaround:
25+ As a workround for a broken systemd-nspawn that returns
26+ EPERM when a syscall is not allowed instead of ENOSYS
27+ we must check for EPERM here and fall back to faccessat. */
28+ if (ret == 0 || !(errno == ENOSYS || errno == EPERM))
29 return ret;
30
31 if (flag & ~(AT_SYMLINK_NOFOLLOW | AT_EACCESS))