update-manager failed to run today on my system. When I investigated, I found this:
$ sudo apt -f install
apt: relocation error: /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0: symbol
_ZN13pkgSourceList16AddVolatileFilesER11CommandLinePSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS8_EE, version APTPKG_5.0 not defined in file libapt-pkg.so.5.0 with link time reference
$ ldd -d -r /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0 2>&1 | grep libapt-pkg
libapt-pkg.so.5.0 => /snap/conjure-up/156/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x00007f5da24bf000)
$ cat /etc/ld.so.conf.d/conjure-up.conf
/snap/conjure-up/156/usr/lib/x86_64-linux-gnu/
$
The conjure-up snap is bundling a copy of libapt-pkg from xenial, which is incompatible with the libapt-private from yakkety.
I see several things wrong with this.
- conjure-up should not be monkeying with the library path of the host system. It appears to have been doing this for some time already before this current version of the snap; it's only the latest version that has added libapt-pkg to the snap and broken things in a way that I noticed, but it was already broken before this for conjure-up to tamper *at all* with the system path.
- this is not the only change that conjure-up makes to the host system from its configure hook. It also creates a file /usr/lib/sysctl.d/60-conjure-up.conf, and manually installs files under /usr/share/bash-completion/completions; and I have no idea what other things it might have done in previous versions of the snap. The system integration goals here are reasonable, but the way conjure-up goes about them are unauditable.
- thirdly, and the reason I'm filing this against snappy: I understand classic snaps being unconfined, by definition. But why does this translate to a classic snap having the power to run an unconfined hook? This is ten times worse than a dpkg maintainer script. For maintainer scripts we have policy around what the script may or may not touch on the filesystem, we have a community process governing who is allowed to upload packages to the Ubuntu archive; for classic snaps we are lacking both of these safeguards. My expectation was that a classic snap would modify the host filesystem only under the user's direction. An unconfined configure hook is a whole other matter entirely.
The confinement of the config hook is a really good idea; we don't want
a general mechanism to deliver bash to a system, we want a general
mechanism to deliver binaries to a system, and the configuration of
those binaries can reasonably be expected to be confined.