adobe-apiplatform/user-sync.py

"error while loading shared libraries: libz.so.1" on systems with /tmp mounted `noexec`

bartreardon opened this issue · 3 comments

Description
On a hardened Ubuntu 20.04 system, /tmp is mounted with noexec. This causes user-sync to fail to run with the following error:

error while loading shared libraries: libz.so.1: failed to map segment from shared object

hardening /tmp is recommended and is required for linux systems in our environment
https://gist.github.com/lokhman/cc716d2e2d373dd696b2d9264c0287a3#secure-tmp-and-vartmp

Steps to reproduce
system: Ubuntu 20.04

run sudo mount /tmp -o remount,noexec,nodev,nosuid to re-mount /tmp and disallow execution

run user-sync --version to observe the error

Expected behavior
user-sync should be able to handle hardened systems

alternately: document the behaviour of user-sync on hardened systems and level of compatability

Environment

  • UST version: 2.7.3
  • OS type and version: Ubuntu Server 20.04 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

the following will work as a workaround

$ TMPDIR=/some/other/tmp
$ export TMPDIR
$ user-sync --version
user-sync 2.7.3

Thank you for bringing this to my attention. I'm not sure that there's anything we can do here, but I will take a look.

The challenge is that the UST uses PyInstaller to bundle the app + Python environment + dependencies in a single executable file. The bundle must be extracted somewhere at runtime in order to run. It uses the system temp directory as the root for the bundle directory.

I can't find a way to override this behavior at runtime. There is a build-time option to customize the bundle directory, but we can't generalize a solution around that. You're free try building the application on your own environment with that option enabled. You'll want to update the pyinstaller invocation in the Makefile.

Otherwise, I think your suggested workaround is the best solution for the time being. I'll plan to update the documentation and see if I can find any other possible solutions.

I'm comfortable recommending resetting TMPDIR as the best solution (short of making sure the UST user has read/write/exec privileges on /tmp).

I've documented it on 20ebaeb which will be published on the next release.