Fix for bug #1572664 had broken my snap package build

[Christopher Townsend]

I'm trying to build a snap package that contains a chroot. In the chroot are many symlinks. Those symlinks point to dead links from the host's perspective, but when inside the chroot, the symlinks are fine.

I could build the snap before the fix for bug #1572664, but now it fails due to dead symlinks. Here is the output:

$ snapcraft snap
Skipping pull puritine (already ran)
Skipping pull libertine (already ran)
Preparing to build puritine
Building puritine
[Errno 2] No such file or directory:
'/home/townsend/puritine/puritine/parts/puritine/build/libertine-data/libertine-container/puritine/rootfs/etc/alternatives/policytool.1.gz'

Is it possible to have some sort of build option to allow dead symlinks when building a snap package?

[Kyle Fazzari (kyrofa)]

Did the review tools give your previous snaps a clean bill of health? They're typically pretty stringent about symlinks reaching outside of the snap.

[Christopher Townsend (townsend)]

I do not recall seeing any warnings or errors when I previously built the snap. All I did was 'snapcraft snap', so I'm not sure if that invokes the review tools.

[Kyle Fazzari (kyrofa)]

Did you ever upload them to the store and undergo the automated review?

[Sergio Schvezov (sergiusens)]

El 26/04/16 a las 11:13, Christopher Townsend escribió:
> I do not recall seeing any warnings or errors when I previously built
> the snap. All I did was 'snapcraft snap', so I'm not sure if that
> invokes the review tools.

snapcraft does not run the review tools for you. You can do that
manually by running

`click-review <snap>`

The reason the referenced bug was fixed like it was, was to avoid being
blocked when uploading to the store. If you have a specific use case I
would advocate talking to the security team about this.

BTW, How are you debbootstrapping? It feels like all this could be
nicely wrapped into a libertine plugin.

[Christopher Townsend (townsend)]

@kyrofa
No, never tried to upload them and undergo the automated review. This is a proof of concept for snaps made using Libertine.

@sergiusens
Ok, click-review is the tool. I'll keep that in mind.

I actually build the chroot via a Debian package in a PPA (https://launchpad.net/~libertine-team/+archive/ubuntu/puritine-devel/+packages), and then download the .deb and extract it into the puritine snap directory. A couple of things to mention.

One, I'm using Puritine as a baseline because it's a known commodity that is already shipping. Two, I build it in a PPA instead of my local machine, because I think a PPA is a more official place to build.

That said, Puritine wraps the Libertine tools to create the bespoke container. Since the chroot is being extracted on a different machine and moved from it's original place, symlinks are going to be broken, no matter what.

I do have plans for a libertine plugin that will build the container with targeted apps, but I wanted to start with something that is known. Also, even if the container is built with the plugin, when the snap with the chroot is installed, the symlinks will be broken wrt to the host machine.

I hope this answers it for you. If not, you can ping me (ChrisTownsed) on irc we can discuss further. Thanks!

[Kyle Fazzari (kyrofa)]

> If you have a specific use case I would advocate talking to the security team about this.

I agree. If the security team (and by extension the review tools) OK this, then it's something we should support.

[Jamie Strandboge (jdstrand)]

IIUC, the symlinks in the snap might point to /usr/lib/foo which point outside the snap from the POV of the review tools since they have no idea you are using a chroot. AppArmor mediation will resolve those symlinks when the program runs and make sure that everything is safe, so this doesn't matter from a security POV.

However, the checks were added because it usually indicates a real problem with the snap-- ie, it is trying to access something outside the app-specific areas and will be known to fail. I've personally seen this happen with snaps. One could argue that this is precisely what --devmode is for, and if people agree that the check is doing more harm than good, I'll remove it.

That said, even if we fixed things I'm pretty sure the sandboxing isn't going to allow you to do what you want with chroot'ing and that we'll need a new interface.

[Kyle Fazzari (kyrofa)]

> I've personally seen this happen with snaps.

Same here, which is why bug #1572664 existed (and was fixed). I'm okay letting people shoot themselves in the foot though (with a let-me-shoot-myself option of some kind). I think the review tools catching this is truly useful in most cases though... could we make that some sort of warning instead?