I am trying to hack into an existing third party snap to work around a bug in it, by adding a executable binary (curl) that its owners missed.
I have managed to unpack the snap from /var/lib/snap, add the missing file, repack and remount it. I can see the file in the corresponding directory in /snap. But the snap still fails to find it! I even ran it under strace and I see that it gets an ENOENT when trying to launch curl.
I suspect that it is somehow caused by apparmor, because apparmor does not allow the snap to execute any “unauthorized” processes, but I can’t tell how this is controlled. I also can’t figure out how to turn off apparmor for this particular snap (if I try to disable apparmor, snaps refuse to launch because they expect to be confined.)
Of course, if you like driving your car with dodgy wheels, there’s a better way to do it, where the wheels might at least spin.
Rather than putting the files back in /snap/ which doesn’t work because they’re not properly recognised, keep the unsquashed-fs in $HOME and instead try it with sudo snap try squashfs-root
Most changes now are instant and this is how you’re expected to do the kind of work you’re doing. Once you’re happy with it, you can snap pack --compression=lzo squashfs-root and get a .snap file back that’d work with Oliver’s command above.
In no situation should you be manipulating any of the contents of /snap by hand and I’d reckon the simple answer for ENOENT is because when you try run the app, the sandboxed environment will restore the mount back to how it was actually intended to be rather than how you’ve changed it. That or it breaks entirely and you get ENOENT because /snap effectively becomes empty, but I’d have expected breakages before that point if so.
