Skip to content
Snippets Groups Projects
  1. Jul 07, 2020
  2. Jun 12, 2020
    • Simon McVittie's avatar
      ld-libs: Always clear ldlibs->needed entry if ld_lib_open() fails · ac3f0295
      Simon McVittie authored
      
      This is what was documented to happen.
      
      Previously, we did not clear the entry if we failed to open the
      library fd, or if we succeeded but the library was "unacceptable"
      (wrong ELF class or machine tag). Normally this results in a minor
      memory leak, and a fd leak if the library is "unacceptable".
      
      However, when called from search_ldcache_cb(), it's particularly
      important that we do this, because search_ldcache() uses the state
      of the fd field - valid fd or not - to check whether ld_lib_open()
      succeeded.
      
      One practical symptom is that if your container has an x86_64
      libfoo.so.0 that compares newer than the provider's libfoo.so.0,
      and does not have an i386 libfoo.so.0, then capsule-capture-libs
      would unexpectedly not capture the i386 libfoo.so.0 from the provider
      either.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      ac3f0295
  3. Jun 03, 2020
  4. Nov 14, 2019
    • Simon McVittie's avatar
      Revert "capture-libs: Compare symbols and versions to determine order" · 6d9833be
      Simon McVittie authored
      
      This crashes when tests/capture-libs.pl loads libgobject-2.0.so.0 on
      Debian 10 'buster' or on Debian unstable:
      
          Stack trace of thread 87172:
          #0  0x00007f6cad431176 g_slice_free1 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2)
          #1  0x00007f6cad431bc0 g_slist_remove (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2)
          #2  0x00007f6cad43bf47 g_once_init_leave (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2)
          #3  0x00007f6cad4f8e24 n/a (/tmp/fpzde0iMLo/host/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6200.2)
      
      I suspect this might be because the version of GLib in /usr and the
      version in /tmp/.../host/usr both get loaded into the same address
      space?
      
      This reverts commit fff84ffb.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      6d9833be
  5. Nov 11, 2019
  6. Sep 26, 2019
    • Simon McVittie's avatar
      capture-libs: Treat unversioned libraries as in indeterminate order · d3d888c9
      Simon McVittie authored
      
      On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular
      file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most
      shared libraries.
      
      However, on Fedora 30 it is a symlink to a versioned name like
      libgcc_s-9-20190827.so.1. The name used in Fedora happens to be less
      than libgcc_s.so.1 in strverscmp() order, causing capsule-capture-libs
      to prefer the Debian/Manjaro libgcc_s.so.1, even if the container is
      older. This can cause problems if an old Debian-derived container like the
      Steam Runtime is used on a newer Fedora host, with host graphics drivers
      imported by using capsule-capture-libs: the container's libgcc_s.so.1
      does not satisfy the versioned symbol requirements of the graphics driver,
      causing loading to fail.
      
      Treat a regular file libgcc_s.so.1 as indeterminate order (or "equal"),
      so that we fall back to the default behaviour, which is currently to
      take the host version of the library in the case of a tie.
      
      This is a stopgap solution: ideally we would consider the versioned
      symbols exported by both libraries, and take whichever one has a superset
      of the version definitions exported by the other, if there is a strict
      superset in either direction (in the case of libgcc, in fact there is).
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d3d888c9
    • Simon McVittie's avatar
      Revert "WIP: capture-libs: Treat unversioned libraries as in indeterminate order" · 702fc558
      Simon McVittie authored
      
      This reverts commit faf3daa9, which
      was merged with an outdated commit message.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      702fc558
  7. Sep 19, 2019
    • Simon McVittie's avatar
      WIP: capture-libs: Treat unversioned libraries as in indeterminate order · faf3daa9
      Simon McVittie authored
      On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular
      file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most
      shared libraries. However, on Fedora 30 it is a symlink to a versioned
      name like libgcc_s-9-20190827.so.1.
      
      This can cause problems if a Debian-derived container is used on a Fedora
      host, with host graphics drivers.
      
      TODO: it isn't clear whether this change makes any practical difference,
      because strverscmp("libgcc_s.so.1", "libgcc_s-9-20190827.so.1") == 0
      anyway.
      faf3daa9
  8. Sep 18, 2019
  9. Jul 25, 2019
  10. Jul 24, 2019
    • Simon McVittie's avatar
      capture-libs: Don't capture results of path-match if they are other ABIs · 723acab2
      Simon McVittie authored
      
      On Red Hat-derived OSs, /usr/lib/dri contains 32-bit drivers (with
      their 64-bit equivalents in /usr/lib64/dri), but on Arch Linux-derived
      OSs it contains 64-bit drivers (with their 32-bit equivalents in
      /usr/lib32/dri). As a result, we have to run both
      i386-linux-gnu-capsule-capture-libs and
      x86_64-linux-gnu-capsule-capture-libs against
      if-exists:path-match:/usr/lib/dri/*.so, ignoring anything we find that
      is of the other word-size.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      723acab2
  11. Apr 16, 2019
  12. Apr 02, 2019
  13. Jan 30, 2019
  14. Apr 27, 2018
  15. Apr 26, 2018
  16. Apr 24, 2018
  17. Jan 03, 2018
  18. Dec 20, 2017
Loading