From 744bd637628f7018be83ee519b4253aac4f028d7 Mon Sep 17 00:00:00 2001
From: Richard Hughes <richard@hughsie.com>
Date: Tue, 1 Feb 2022 14:10:04 +0000
Subject: [PATCH] Handle EPERM to allow Fedora to be used on CircleCI and
 GitHub actions

It appears both CI systems are running docker with an old libseccomp
that doesn't have __SNR_close_range which the latest GLib hard-depends
on.

Relax the requirements a little until the two most popular CI systems
have deployed a new enough docker image.
---
 glib2.spec         |  4 ++++
 gspawn-eperm.patch | 43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+)
 create mode 100644 gspawn-eperm.patch

diff --git a/glib2.spec b/glib2.spec
index 92bb607..2eacc2b 100644
--- a/glib2.spec
+++ b/glib2.spec
@@ -16,6 +16,10 @@ Patch0: gnutls-hmac.patch
 # https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3501
 Patch1: 0001-gmain-Add-a-missing-return-on-error-path-in-g_main_c.patch
 
+# recent close_range() changes break CircleCI and GitHub actions -- we can remove this when
+# the baremetal Docker is updated there i.e. lets be a little bit pragmatic...
+Patch2: gspawn-eperm.patch
+
 BuildRequires: gcc
 BuildRequires: gcc-c++
 BuildRequires: gettext
diff --git a/gspawn-eperm.patch b/gspawn-eperm.patch
new file mode 100644
index 0000000..f233bc9
--- /dev/null
+++ b/gspawn-eperm.patch
@@ -0,0 +1,43 @@
+diff --git a/glib/gspawn.c b/glib/gspawn.c
+index 67be6a6af..aaefd5b0d 100644
+--- a/glib/gspawn.c
++++ b/glib/gspawn.c
+@@ -1533,9 +1533,18 @@ safe_fdwalk_set_cloexec (int lowfd)
+    *
+    * Handle ENOSYS in case it’s supported in libc but not the kernel; if so,
+    * fall back to safe_fdwalk(). Handle EINVAL in case `CLOSE_RANGE_CLOEXEC`
+-   * is not supported. */
++   * is not supported.
++   *
++   * Also handle EPERM for the cases where GLib is running under broken versions
++   * of Docker+libseccomp which don’t recognise `close_range()` so block calls
++   * to it under a default security policy which returns EPERM rather than (the
++   * correct) ENOSYS. This workaround should be carried in distributions until
++   * they have versions of libseccomp and Docker which contain:
++   *  - https://salsa.debian.org/debian/libseccomp/-/blob/debian/bullseye/debian/patches/syscalls_add_close_range_syscall.patch
++   *  - https://github.com/opencontainers/runc/issues/2151
++   */
+   int ret = close_range (lowfd, G_MAXUINT, CLOSE_RANGE_CLOEXEC);
+-  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL))
++  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL || errno == EPERM))
+     return ret;
+ #endif  /* HAVE_CLOSE_RANGE */
+   return safe_fdwalk (set_cloexec, GINT_TO_POINTER (lowfd));
+@@ -1586,9 +1595,15 @@ safe_closefrom (int lowfd)
+    * situations: https://bugs.python.org/issue38061
+    *
+    * Handle ENOSYS in case it’s supported in libc but not the kernel; if so,
+-   * fall back to safe_fdwalk(). */
++   * fall back to safe_fdwalk().
++   *
++   * Also handle EPERM for the cases where GLib is running under broken versions
++   * of Docker+libseccomp which don’t recognise `close_range()` so block calls
++   * to it under a default security policy which returns EPERM rather than (the
++   * correct) ENOSYS.
++   */
+   int ret = close_range (lowfd, G_MAXUINT, 0);
+-  if (ret == 0 || errno != ENOSYS)
++  if (ret == 0 || !(errno == ENOSYS || errno == EPERM))
+     return ret;
+ #endif  /* HAVE_CLOSE_RANGE */
+   return safe_fdwalk (close_func, GINT_TO_POINTER (lowfd));