snaps complain about being unable to open ld preloads

[Jonathan Kamens]

I get this in email every night:

/etc/cron.daily/ubuntu-advantage-tools:
ERROR: ld.so: object '/usr/lib/libesets_pac.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/libesets_pac.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

NOTE: The shared library in question is part of the ESET antivirus software for Linux. This is NOT a bug in ESET; the shared library path referenced above is a symlink to a valid 64-bit shared library that regular (non-snap) processes are able to preload just fine.

I dug into this, and /etc/cron.daily/ubuntu-advantage-tools calls /usr/bin/ubuntu-advantage status, which calls /snap/bin/canonical-livepatch status, which ends up calling snap-confine, which then fails to open the shared library file:

open("/usr/lib/libesets_pac.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I assume this is because snap-confine is doing a chroot or something like that.

I'm not sure what the right fix is here. Is snap creating a copy of /etc/ld.so.preload in its chroot? If so, should it strip out preloads that aren't in the chroot?

I mean, we can argue about whether it's appropriate to be confining snap processes in such a way that preloads can't be loaded, but if that's the right decision, then it shouldn't complain about them.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: snap (not installed)
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 30 11:32:56 2018
InstallationDate: Installed on 2017-05-19 (345 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: snap
UpgradeStatus: Upgraded to bionic on 2018-04-27 (3 days ago)

[Zygmunt Krynicki (zyga)]

Hello

The preload doesn't work because /usr/lib, from the point of view of the snap application, is not the /usr/lib from your host filesystem. In addition there's no guarantee that the preload library and the snap are ABI compatible (they likely are but this is just coincidence).

[Zygmunt Krynicki (zyga)]

I'm marking this as won't fix. Ideally the error message would not be printed at all but this would involve tricky changes to the dynamic linker that I don't think are warranted. I've explained why this behavior exists in the prior comment. I don't think we can do anything else about it.