Seed credentials in snapd

For Bionic we want to add store/snapd login in the installer. To do this we need a way to “communicate” with the to-be-installed snapd. I see two possible ways:

  1. start the to-be-installed snapd inside the chroot
  2. seed the authentication data into the to-be-installed snapd

Solution (1) presents one major problem: the chroot needs to be ready when we ask the user to login. This will cause a poor UI experience beacuse the user needs to wait (minutes not seconds).

Solution (2) works in this way:

  1. The installer uses the v2/login API from the livecd snapd
  2. The installer reads the livecd state.json and takes part of the auth field (last-id, users, and macaroon-key) and stores it in /target/var/lib/snapd/seed/auth.json
  3. On first boot the installed snapd checks if /var/lib/snapd/seed/auth.json exists and uses it to pre-initialize the auth field of its state.

Something like this. The final version of course needs to be more e a bit more paranoid about checking the perms of that file.

We already a quick chat on IRC and @pedronis pointed out that this could allow to clone the same creds on a lot of images. Is this really a problem? Also please note that this is already possible (nothing prevents a user to copy-paste the state.json from one machine to another once you get root access).

Please don’t poke at state.json directly. This is not part of the API of snapd, and can easily change in unexpected ways even inside patch releases. In fact, we will remove this file entirely in the foreseeable future, and move to a richer on-disk format.

There’s also a detail to be aware of that is not entirely clear from the problem statement: snapd does not have a global authentication state. It is the user that authenticates, and then it is the actions of that authenticated user that are associated with a particular authorization state. It won’t help much to store authentication data inside snapd if there is no data inside the current state that is associated with that user, and no person outside that knows how to authenticate as that user either.

All of that starts to feel a bit like a can of worms that is too late to open right now.

Any other possible solution that we could use in the short term?

Potentially, but we need to discuss the actual problem first, though. Per the note above, just the workaround described by itself should have no effect in practice, so it sounds like you’re aiming at something else instead, which isn’t completely clear yet.

@seb128 is organizing a call for us to discuss this later in the week.

We could add a snap command to export all the information we need in the required format.