What to do when a closed-source program don't honour $HOME to locate its files?

I’m attempting to fix the issue where ngrok need to save an authtoken in it’s config directory (~/.ngrok2/authtoken), and found out that it doesn’t honor the $HOME environment variable but (possibly) queried it via /etc/passwd (which is the real home directory, not the one in the snap runtime):

It’s less likely that we can change its own code to honor the HOME environment variable, is there any hacks that can workaround this?

The executable seems to be dynamically linked, though:

$ file ngrok
ngrok: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=WurpW0l_bKdI4kv9WPWp/N2JKHdyhG6WVkZMzAaOv/82jPo5YLbjXZotiOUoun/1WB10Ln2gz9Y8HZSFsV-, not stripped
$ ldd ngrok
        linux-vdso.so.1 (0x00007ffe2ba79000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc63c3ed000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc63c202000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc63c434000)

Maybe some dynamic linker magic would help?

Hi there, have you tried using layouts? https://docs.snapcraft.io/snap-layouts

How would the layouts feature help with this situation?

Layouts are about exposing things from SNAP, SNAP_DATA and SNAP_COMMON to other parts of the filesystem. It isn’t explicitly listed in the documentation page you listed, but SNAP_USER_DATA and SNAP_USER_COMMON are not currently supported, which is needed for supporting /home.

1 Like

Likely. You can strace the application and see what it is doing (likely getpwent) and then craft an LD_PRELOAD.

1 Like