Ubuntu – devmode for snaps

Snapcraft is a set of tools bundled under the snapcraft command to easily create (craft) packages for multiple Linux distributions. These .snap packages generally contain self-contained apps, provide secure isolation and are installable either from the Ubuntu Software Store or manually via the snap install <snap-name>.snap command.

In a nutshell, as a developer you would write code using your regular tools, and let Snapcraft take care of assembling it for distribution. Snapcraft also excels in enabling developers port their existing apps to any snap-enabled Linux platform.

Snapcraft:

• Is intelligent: it fetches, builds and assembles diverse pieces of software (parts) from remote sources into a final .snap package, which contains all dependencies it needs to function
• Needs a recipe: it relies on a snapcraft.yaml file that specifies the parts and plugins required to create the package
• Is extensible with plugins. While it ships with a set of the most common build system plugins to cater for a wide range of app builds, it can be easily extended with new ones.

The 3-minute Snapcraft tour

Install Snapcraft on Ubuntu

You will need Ubuntu 16.04 LTS to use Snapcraft. Open a terminal with Ctrl+Alt+t and simply install Snapcraft with this command:

sudo apt install snapcraft
sudo apt install build-essential  # Optional, but useful for different builds

If you are using another distro, check out the alternative installation instructions >

Test-drive Snapcraft

The following example crafts a package that contains a service that allows you to paste and share. Once finished, you can install it manually on your snappy device for testing purposes or upload it to the Store for other users.

First of all we open a terminal and download the example from the examples repository:

sudo apt install git
git clone https://github.com/ubuntu-core/snapcraft.git
cd snapcraft/demos/gopaste

Notice the snapcraft.yaml file in that directory, which specifies a service and the parts required to assemble the final .snap. You can optionally examine it with a text editor.

Now run the snapcraft command on the terminal. This will cause all snapcraft subcommands to run in sequence to build the parts and put the results in the final .snap package. During development, you would normally run the steps separately until you are confident that the whole build and assembly works.

$ snapcraft 
Pulling gopaste 
env GOPATH=/tmp/snapcraft/examples/gopaste/parts/gopaste/build go get -t -d github.com/wisnij/gopaste/gopasted
Building gopaste 
env GOPATH=/tmp/snapcraft/examples/gopaste/parts/gopaste/build go build github.com/wisnij/gopaste/gopasted
env GOPATH=/tmp/snapcraft/examples/gopaste/parts/gopaste/build go install github.com/wisnij/gopaste/gopasted
env GOPATH=/tmp/snapcraft/examples/gopaste/parts/gopaste/build cp -a /tmp/snapcraft/examples/gopaste/parts/gopaste/build/bin /tmp/snapcraft/examples/gopaste/parts/gopaste/install
Staging gopaste 
Snapping gopaste 
Generated 'gopaste_1.0_amd64.snap' snap

On the output of the command you can see the steps snapcraft runs for you:

1. Pull: it pulls the code from the required gopaste part from a remote Github repo
2. Build: it builds gopaste locally
3. Stage: after the build, the parts are put into a single directory tree, the "staging area"
4. Snap: the final .snap package is created from the assembled parts in the staging area

Notes:

• You'll find the final snap file as gopaste_1.0_amd64.snap (notice in my case I built it on my amd64 desktop, e.g. Raspberry Pi 2 packages would have the _armhf architecture suffix).
• You can also run each command individually: snapcraft pull, snapcraft build, snapcraft stage or snapcraft snap
• Use snapcraft -h for a quick overview of all commands available.

And that's it for a quick glimpse of what Snapcraft can do! Learn more about Snapcraft >

This specifically relates to snaps that use X11. In other words, snaps are not running unconfined, but if the confinement of the snap includes access to X, then yeah: it has access to X. It does not involve snaps that don't use the unity7 or x11 interfaces. The issue described in that blog post is a well-known limitation of X, and is one of the reasons alternative technologies are being developed (e.g. Mir).

Gustavo Niemeyer has written a good blog post that discusses this. I'll quote here for posterity and completeness:

The security minded will observe that X11 is not in fact a secure protocol. A number of system abuses are possible when we hand an application this permission. Other interfaces such as home would give the snap access to every non-hidden file in the user’s $HOME directory (those that do not start with a dot), which means a malicious application might steal personal information and send it over the network (assuming it also defines a network plug).

Some might be surprised that this is the case, but this is a misunderstanding about the role of snaps and Snappy as a software platform. When you install software from the Ubuntu archive, that’s a statement of trust in the Ubuntu and Debian developers. When you install Google’s Chrome or MongoDB binaries from their respective archives, that’s a statement of trust in those developers (these have root on your system!). Snappy is not eliminating the need for that trust, as once you give a piece of software access to your personal files, web camera, microphone, etc, you need to believe that it won’t be using those allowances maliciously.

The point of Snappy’s confinement in that picture is to enable a software ecosystem that can control exactly what is allowed and to whom in a clear and observable way, in addition to the same procedural care that we’ve all learned to appreciate in the Linux world, not instead of it. Preventing people from using all relevant resources in the system would simply force them to use that same software over less secure mechanisms instead of fixing the problem.

And what we have today is just the beginning. These interfaces will soon become much richer and more fine grained, including resource selection (e.g. which serial port?), and some of them will disappear completely in favor of more secure choices (Unity 8, for instance).