Problem description

When I run chromium in a bash shell, I get this message: ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (failed to map segment from shared object): ignored. However, when I run a regular executable, such as a helloworld program compiled by gcc, the error message isn't generated.

Platform

My research

I use ldd to locate libgtk3-nocsd.so.0 and it turns out that both helloworld and chromium can correctly find the absolute path of that shared object.

$ ldd helloworld | grep -F libgtk3-nocsd.so.0
    libgtk3-nocsd.so.0 => /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0 (0x0000ffffa9a73000)

$ ldd /snap/bin/chromium | grep -F libgtk3-nocsd.so.0
    libgtk3-nocsd.so.0 => /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0 (0x0000ffff7e370000)

$ ldd /snap/chromium/current/usr/lib/chromium-browser/chrome | grep -F libgtk3-nocsd.so.0
    libgtk3-nocsd.so.0 => /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0 (0x0000ffff7a299000)

Some information about the libgtk3-nocsd.so.0 shared object are listed below. Pay attention that there's a setuid bit in its access rights.

$ ls -l /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0 
-rwSr--r-- 1 root root 26464 Mar  3  2018 /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0

The $LD_PRELOAD environment variable is set here:

$ sudo grep -2r LD_PRELOAD /etc/
...
/etc/X11/Xsession.d/51gtk3-nocsd-detect-          if [ x"$GTK_CSD"x = x"0"x ] ; then
/etc/X11/Xsession.d/51gtk3-nocsd-detect:              export LD_PRELOAD="libgtk3-nocsd.so.0${LD_PRELOAD:+:$LD_PRELOAD}"
/etc/X11/Xsession.d/51gtk3-nocsd-detect-          fi
...

The following document might account for this problem?

$ sudo grep -2r LD_PRELOAD /etc/
...
/etc/apparmor.d/abstractions/ubuntu-helpers-  # While the chromium and chrome sandboxes are setuid root, they only link
/etc/apparmor.d/abstractions/ubuntu-helpers-  # in limited libraries so glibc's secure execution should be enough to not
/etc/apparmor.d/abstractions/ubuntu-helpers:  # require the santized_helper (ie, LD_PRELOAD will only use standard system
/etc/apparmor.d/abstractions/ubuntu-helpers-  # paths (man ld.so)).
...

$ man ld.so
...
              In  secure-execution  mode, preload pathnames containing slashes are ignored.  Furthermore, shared objects are preloaded only from the stan‐
              dard search directories and only if they have set-user-ID mode bit enabled (which is not typical).
...

My solutions

According to the document above, I've worked out two solutions.

• set $LD_PRELOAD to the absolute path of libgtk3-nocsd.so.0
  The document suggests that LD_PRELOAD will only use standard system paths in the case of the chromium and chrome sandboxes. Therefore, one might replace export LD_PRELOAD="libgtk3-nocsd.so.0${LD_PRELOAD:+:$LD_PRELOAD}" with export LD_PRELOAD="/lib/aarch64-linux-gnu/libgtk3-nocsd.so.0${LD_PRELOAD:+:$LD_PRELOAD}" in /etc/X11/Xsession.d/51gtk3-nocsd-detect and then restart the desktop environment. Pay attention that the absolute path of libgtk3-nocsd.so.0 varies on different platforms.
• run chromium as root without using sandboxes
  The problem seems to be related to the use of the chromium and chrome sandboxes which are setuid root, as is indicated in the document. Running chromium as root without using sandboxes (e.g. sudo chromium --no-sandbox) seems to suppress the error message. Unfortunately, this behaviour might bring about a warning from the browser (You are using an unsupported command-line flag:--no-sandbox. Stability and security will suffer.).

My questions

• What does the so-called standard system paths/standard search directories in the document mean? There is a record of libgtk3-nocsd.so.0 in /etc/ld.so.cache, and /lib/aarch64-linux-gnu is included in /etc/ld.so.conf.d/aarch64-linux-gnu.conf. Isn't /lib/aarch64-linux-gnu a standard system path/standard search directory?

  $ grep -aoP '(?<=\x00)[^\x00]*?libgtk3-nocsd\.so\.0' /etc/ld.so.cache
  libgtk3-nocsd.so.0
  /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0
  
  $ cat /etc/ld.so.conf.d/aarch64-linux-gnu.conf
  # Multiarch support
  /usr/local/lib/aarch64-linux-gnu
  /lib/aarch64-linux-gnu
  /usr/lib/aarch64-linux-gnu
  

• As is illustrated in the document, in secure-execution mode, preload pathnames containing slashes are ignored. Does that mean $LD_PRELOAD will be ignored if it's an absolute path like /lib/aarch64-linux-gnu/libgtk3-nocsd.so.0?
• Which solution is safer and more reasonable? Are there any better solutions? Is there anything else that I misunderstood?