Build will fail when docker has glibc2.34+ and glib2.72+ (close_range EPERM)

[sandy-lcq]

Description
docker has glibc2.35, and build with glib2.72+, the build will fail with error:
(glib-compile-resources:19315): GLib-GObject-CRITICAL **: 08:08:56.312: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
../gdk-pixbuf-2.42.8/tests/resources.gresource.xml: Failed to close file descriptor for child process (Operation not permitted).

The reason is that, close_range treturn EPERM for docker container, .since commit [1], glib will report error, and upstream reject to accpect EPERM as return value.

This issue is a little similar like the issue we met before for clone3, and the fix is [3].

I notice that we have an RFE [4] to make Seccomp Profiles to ENOSYS Default, seems this is the solution,
since glib only will take ENOSYS as correct return.

[1] https://gitlab.gnome.org/GNOME/glib/-/commit/ce04a124040be091407e070280d86ca810bacb8c
[2] https://gitlab.gnome.org/GNOME/glib/-/issues/2580
[3] #42681
[4] #42871

Steps to reproduce the issue:
In order to simple the reproduce steps, I just pick the usefull part

1. docker run --rm -i -t -v /docker/:/mnt ubuntu:22.04 /bin/bash
2. setup yocto project and bitbake gdk-pixbuf-native
   the actually failed command is:
   glib-compile-resources --sourcedir=/mnt/ubuntu2204/build/tmp-glibc/work/x86_64-linux/gdk-pixbuf-native/2.42.8-r0/gdk-pixbuf-2.42.8/tests --source ../gdk-pixbuf-2.42.8/tests/resources.gresource.xml tests/resources.c

While glib-compile-resources is build from glib 2.72.1

Describe the results you received:

(glib-compile-resources:19315): GLib-GObject-CRITICAL **: 08:08:56.312: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
../gdk-pixbuf-2.42.8/tests/resources.gresource.xml: Failed to close file descriptor for child process (Operation not permitted).
Describe the results you expected:
build success

Additional information you deem important (e.g. issue happens only occasionally):
Issue not happens on docker ubuntu2104 which have glibc 2.33,
close_range is added in glibc since 2.34

Output of docker version:

Docker version 20.10.12, build e91ed57

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  scan: Docker Scan (Docker Inc., v0.12.0)

Server:
 Containers: 10
  Running: 2
  Paused: 0
  Stopped: 8
 Images: 37
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.13.0-35-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 48
 Total Memory: 247.3GiB
 Name: core2
 ID: H5SQ:4MGO:KUUX:QJUT:QDJS:CVO2:WXHZ:KKUM:6WVI:VSIP:7PP3:6T67
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
 Live Restore Enabled: false

[sandy-lcq]

Hi, @thaJeztah

Can you share any plan about fixing this issue? Thanks.

[thaJeztah]

Do you have a minimal way to reproduce this issue (using just a plain docker build without yocto and other things to set up)?

I see these PRs updated the seccomp profile to add close_range to the allow list;

• profiles: seccomp: update to Linux 5.11 syscall list #41889
• [20.10 backport] profiles: seccomp: update to Linux 5.11 syscall list #41971

The last one is part of docker 20.10.14 and up.

[sandy-lcq]

@thaJeztah

It can be reproduced by following steps:

1. docker run -i -t -v /docker/:/mnt ubuntu:22.04 /bin/bash
2. apt-get update
3. apt-get install gcc
4. mkdir -p /mnt/test; cd /mnt/test; touch test.c
5. test.c is the example application from link: https://man7.org/linux/man-pages/man2/close_range.2.html.
6. root@1c5d131f6984:/mnt/test# gcc test.c
   root@1c5d131f6984:/mnt/test# touch /tmp/a /tmp/b /tmp/c
   root@1c5d131f6984:/mnt/test# ./a.out /tmp/a /tmp/b /tmp/c
   /tmp/a opened as FD 3
   /tmp/b opened as FD 4
   /tmp/c opened as FD 5
   /proc/self/fd/0 ==> /dev/pts/0
   /proc/self/fd/1 ==> /dev/pts/0
   /proc/self/fd/2 ==> /dev/pts/0
   /proc/self/fd/3 ==> /tmp/a
   /proc/self/fd/4 ==> /tmp/b
   /proc/self/fd/5 ==> /tmp/c
   /proc/self/fd/6 ==> /proc/817/fd
   ========= About to call close_range() =======
   close_range: Operation not permitted

Seems #41971 add close_range, but don't set the default errno to ENOSYS, and EPERM is returned, after commit https://gitlab.gnome.org/GNOME/glib/-/commit/ce04a124040be091407e070280d86ca810bacb8c, glib2 will report error.

Maybe we need change like
9f6b562#diff-ae1c2d16350cc6adbb1802390cbd195657d5562dd804e0dcc62607213a186c2b
to make close_range return ENOSYS.

More info:

1. I test with docker version 20.10.20, issue can be reproduced
2. issue can be workaround by add "--security-opt seccomp=unconfined" when running "docker run"

[cpuguy83]

libseccomp did not have support for close_range until version 2.5.2, ubuntu 20.04 (from your host) and even 22.04 only include 2.5.1.

It looks like Debian backported the patch to add support for close_range to their 2.5.1 package.

[sandy-lcq]

@cpuguy83 I checked on the docker 22.04, it seems have 2.5.3

$ docker run -i -t -v /docker/:/mnt ubuntu:22.04 /bin/bash
root@84df2cf7ae02:/# ls -al /usr/lib/x86_64-linux-gnu/libseccomp.so.2*
lrwxrwxrwx 1 root root 19 Mar 17 2022 /usr/lib/x86_64-linux-gnu/libseccomp.so.2 -> libseccomp.so.2.5.3
-rw-r--r-- 1 root root 125360 Mar 17 2022 /usr/lib/x86_64-linux-gnu/libseccomp.so.2.5.3
root@84df2cf7ae02:/#

[tianon]

It's the libseccomp2 version on the host which matters here (not inside the container). 😅

[Rid]

Looks like it's been updated in ubuntu 22.04.1:

libseccomp2:
  Installed: 2.5.3-2ubuntu2
  Candidate: 2.5.3-2ubuntu2

[thaJeztah]

@Rid does it work as expected with the updated version?

[Rid]

@thaJeztah Yes, using the reproducer:

root@af40cff59393:/mnt/test#  ./a.out /tmp/a /tmp/b /tmp/c
/tmp/a opened as FD 3
/tmp/b opened as FD 4
/tmp/c opened as FD 5
/proc/self/fd/0 ==> /dev/pts/0
/proc/self/fd/1 ==> /dev/pts/0
/proc/self/fd/2 ==> /dev/pts/0
/proc/self/fd/3 ==> /tmp/a
/proc/self/fd/4 ==> /tmp/b
/proc/self/fd/5 ==> /tmp/c
/proc/self/fd/6 ==> /proc/994/fd
========= About to call close_range() =======
/proc/self/fd/0 ==> /dev/pts/0
/proc/self/fd/1 ==> /dev/pts/0
/proc/self/fd/2 ==> /dev/pts/0
/proc/self/fd/3 ==> /proc/994/fd
root@af40cff59393:/mnt/test#

I think this can be closed.

[thaJeztah]

Thank you! That's always good to hear; I'll close the ticket, but feel free to continue the conversation 👍

[wtdcode]

In case someone is looking for a workaround without upgrading the libseccomp2 of the host...

RUN apt purge -y libglib2.0-*  && cd /tmp && echo "deb-src https://archive.ubuntu.com/ubuntu/ jammy-updates main restricted" >> /etc/apt/sources.list &&\
    apt update && apt install -y dpkg-dev python3-dbusmock && apt-get source libglib2.0-0 && cd glib2.0-* && sed -i "/close_range/d" meson.build &&\
    DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends tzdata &&\
    apt build-dep -y libglib2.0-0 && env CC=gcc CXX=g++ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -uc -b &&\
    cd .. && dpkg -i *.deb