10000 Build will fail when docker has glibc2.34+ and glib2.72+ (close_range EPERM) · Issue #43595 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

New issue

Have a question about this project? Sign up for a free 8000 GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
sandy-lcq opened this issue May 13, 2022 · 11 comments
Closed

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

sandy-lcq opened this issue May 13, 2022 · 11 comments
Labels
area/security/seccomp kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. version/20.10
Milestone
23.0.0

Comments

@sandy-lcq
Copy link
sandy-lcq commented May 13, 2022 •
edited
Loading

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
@AkihiroSuda AkihiroSuda added kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. area/security/seccomp version/20.10 labels May 13, 2022
@AkihiroSuda AkihiroSuda changed the title Build will fail when docker has glibc2.35 and glib2.72+ Build will fail when docker has glibc2.35 and glib2.72+ (close_range EPERM) May 13, 2022
@thaJeztah thaJeztah added this to the 22.06.0 milestone May 13, 2022
@jeremypw jeremypw mentioned this issue Jul 17, 2022
Merged
@danirabbit danirabbit mentioned this issue Jul 28, 2022
Closed
@ifurther ifurther mentioned this issue Aug 9, 2022
Closed
wdconinc added a commit to wdconinc/spack that referenced this issue Aug 30, 2022
@wdconinc
gdk-pixbuf: only build tests when requested
475df7d 
The building of tests is optional [as of 2.42.9](https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/801eef111df624f4377baed9a90c94b6a2d4340c). This applies this option in the build.

The reason the option was added was to deal with test build failures in sandboxed environments and with certain glibc versions (caused by glib gresources). For example, with the latest version glibc and in the latest version of docker these tests [cannot be built](moby/moby#43595).
@wdconinc wdconinc mentioned this issue Aug 30, 2022
Merged
tldahlgren pushed a commit to spack/spack that referenced this issue Aug 31, 2022
@wdconinc
gdk-pixbuf: only build tests when requested (#32452)
c75c27c 
The building of tests is optional [as of 2.42.9](https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/801eef111df624f4377baed9a90c94b6a2d4340c). This applies this option in the build.

The reason the option was added was to deal with test build failures in sandboxed environments and with certain glibc versions (caused by glib gresources). For example, with the latest version glibc and in the latest version of docker these tests [cannot be built](moby/moby#43595).
ma595 pushed a commit to ma595/spack that referenced this issue Sep 13, 2022
@wdconinc @ma595
gdk-pixbuf: only build tests when requested (spack#32452)
d1f3fc5 
The building of tests is optional [as of 2.42.9](https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/801eef111df624f4377baed9a90c94b6a2d4340c). This applies this option in the build.

The reason the option was added was to deal with test build failures in sandboxed environments and with certain glibc versions (caused by glib gresources). For example, with the latest version glibc and in the latest version of docker these tests [cannot be built](moby/moby#43595).
@carlocab carlocab mentioned this issue Sep 26, 2022
Closed
6 tasks
@sandy-lcq
Copy link
Author

Hi, @thaJeztah

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

@sandy-lcq sandy-lcq changed the title Build will fail when docker has glibc2.35 and glib2.72+ (close_range EPERM) Build will fail when docker has glibc2.34+ and glib2.72+ (close_range EPERM) Oct 19, 2022
@thaJeztah
Copy link
Member

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;

The last one is part of docker 20.10.14 and up.

@sandy-lcq
Copy link
Author

@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"

@jf2048 jf2048 mentioned this issue Oct 26, 2022
Merged
@cpuguy83
Copy link
Member

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
Copy link
Author

@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
Copy link
Member
tianon commented Oct 31, 2022

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

@danielnachun danielnachun mentioned this issue Nov 29, 2022
Closed
6 tasks
@Rid
Copy link
Contributor
Rid commented Dec 12, 2022

Looks like it's been updated in ubuntu 22.04.1:

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

@thaJeztah
Copy link
Member

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

@Rid
Copy link
Contributor
Rid commented Dec 12, 2022

@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
Copy link
Member

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

@wtdcode
Copy link
wtdcode commented Feb 22, 2023 •
edited
Loading

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 http://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

@geigi geigi mentioned this issue Dec 3, 2023
Merged
@stu-spp stu-spp mentioned this issue May 8, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/security/seccomp kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. version/20.10
Projects
None yet
Milestone
23.0.0
Development

No branches or pull requests
7 participants
@tianon @cpuguy83 @thaJeztah @Rid @AkihiroSuda @wtdcode @sandy-lcq
0