Classic confinement for bootstack-ops snap

@jdstrand, @niemeyer, yes it’s read-only access to ~/.local/share/juju that I’m looking for - no write required. Having a juju-client-observe interface would be absolutely perfect for my use case, I hadn’t even considered that adding an interface might be an option. I might need a little advice on how to access the directory since $HOME is specific to the snap, but there’s an env var I can use for juju client config which can remap me back to the right place. Currently, if I add JUJU_DATA=${HOME}/.local/share/juju’ to the env from which I call the snap (i.e. before $HOME is remapped), I seem to get the right result. If there’s a way to trigger the interface to avoid having to edit .bashrc that would be ideal, but not essential.

We will also want access to the juju binary, which is in the path via /snap/bin but might also be from a .deb, depending on the history of the machine.

Thanks so much for the detailed information here, it’s something I think a number of folks might find useful.

It turns out there were a number of items that meant the Juju client snap needed classic, from the README in the repo:

Needed for confinement

To enable strict mode, the following bugs need to be resolved, and the snap updated accordingly.

I can write this. I’ve added it to my todo and should have something up for review later today.

You can always call ‘getent’ to get the home for the user as opposed to the home for the snap. Eg: getent passwd $UID | cut -d ':' -f 6.

“Missing support for abstract unix sockets ( )”
There is an open question on this in the bug. The last time I talked to Nicholas I was under the impression this was no longer needed. Also note new support for socket, socket-mode and listen stream (Snapcraft.yaml reference) that may help you in this area

“Needs SSH interface ( )”
This should be DONE (we now have both ssh-keys and ssh-publis-keys interfaces)

“Bash completion doesn’t work ( )”
This should be DONE. You might try looking into @chipaca’s excellent bash completion work: Tab completion for snaps

“Juju plugin support ( )”
This doesn’t seem to be a snapd deficiency (please correct if I’m wrong). We now have a content interface (The content interface) that should allow the juju snap to ‘slot’ a read/write area and for plugins to ‘plug’ this slot and write data to it. How you organize it, do registration, etc is completely up to you

Can you verify the above and confirm if anything else is still needed?

FYI, juju-client-observe is merged into master and the upcoming 2.33.

1 Like

The Juju plugin protocol requires the ‘juju’ command line tool to execute arbitrary programs on $PATH that begin with ‘juju-’. It seems incompatible with confined snaps, and changing it would technically be a backwards incompatible change and shouldn’t be done until Juju 3.0 (to eg. require plugins to be installed in /snap somewhere, or be distributed as snaps that are plugged into the Juju snap)

I’m not familiar with the juju plugin protocol (maybe @niemeyer should weigh in on design for strictly confined juju), but it seems like the juju snap could provide a read-only slot that plugin snaps could consume which allows use of the ‘juju’ command (additional interfaces might need to be developed) and the juju snap could provide a read/write slot that plugin snaps could consume to write to. The juju snap is updated to add the read/write area to its PATH. Non-snap juju plugins write to wherever the juju command expects to find them (again, another interface might be needed for the juju snap to have this access, perhaps ‘juju-support’).

I am certainly missing details and don’t have the full picture… but it seems based on my limited understanding that juju could plausibly be strictly confined. @niemeyer - help! :slight_smile:

Now that we have the 2.33 released, I tried to use the new interface to hook up the juju client and get confinement working, but when uploading to the store I get the following:

Error while processing...
The store was unable to accept this snap.
  - interface 'juju-client-observe' not found in base declaration
  - interface 'juju-client-observe' not found in base declaration
  - interface 'juju-client-observe' not found in base declaration
  - unknown plugs interface name reference 'juju-client-observe'
  - unknown plugs interface name reference 'juju-client-observe'
  - unknown plugs interface name reference 'juju-client-observe'

Is there something obvious that I’m missing here? I’ve added the following to the snapcraft.yaml:

    command: something
      - all-the-other-plugs
      - juju-client-observe

It exists here:

$ snap interfaces :juju-client-observe
Slot                  Plug
:juju-client-observe  -

$ snap version 
snap    2.34
snapd   2.34
series  16
ubuntu  18.04
kernel  4.15.0-24-generic

What is the output of snap version?

My build box is 2.33.1, as is the client I’m testing with, and I do see the interface present everywhere. However, it’s when I upload to the store that I get errors, building is OK as is making the connection on install.

This is a bug in the review-tools. I’ll fix that. Please continue to upload to the store in strict and request a manual review and I’ll review the snap as needed until the fix is in production.

This is updated in master and on its way to production.

I’ve had no success at getting the snap confined - mostly because I need access to a Juju binary even if we have the interface to get the client config, and short of including that binary via a deb inside the snap, or a complete compile of the juju client, I’m stuck. This is effectively along the same lines as the Juju plugins that stub mentions. Any chance of a reconsideration for classic confinement?

I’ll add that this repo is a slowly growing list of ops tools that will use the Maas CLI, plus Juju client.

@niemeyer - what are your thoughts on @xavpaice’s most recent comments?

Update: I’ve been asked to remove that particular snap anyway, we’re working on removing the tooling and putting it where it belongs in the product itself, making a separate snap obsolete. I’ve marked the snap private now, and would like some help if possible to delete it from the store.

@xavpaice The store team can help with that, but can you please open an independent thread for this? This issue has been marked solved, which probably will detour eyes away from it.

@xavpaice hi! Snaps aren’t usually deleted; if you want it to be completely unfindable/uninstallable, while still keeping the name in case you want to use it in the future, you can close all channels:

snapcraft close bootstack-ops edge beta candidate stable

and of course, keeping it private makes it even more… private :slight_smile:

If, on the other hand, you absolutely want to entirely banish the snap name from existence (which also means you will never, ever again in the history of the universe, be able to publish a snap under the bootstack-ops name, so you’d better be absolutely sure you want this!) we can delete/revoke the name. I think this may be what you want but I wanted to be very clear on the dire consequences of making this decision. If so, in order to keep a separate paper trail, please do as Gustavo suggested and open a new topic asking for the revocation of the snap. I apologize for the extra step, but consider this an “are you really really sure you want to do that?” kind of action to make you pause and consider things.


  • Daniel

This possibility concerns me. Consider a troll registering the name msoffice or office (both?) and then going through the above procedure to revoke the name. Now we have the possibility that Microsoft comes along and is willing to publish Microsoft Office to the store, but neither of their preferred, and discoverable, names are available because we allowed someone to irrevocably destroy the names…

No need to worry; revocations are scoped by developer, so all the troll would achieve is locking himself out of those names :slight_smile: Revocation means “I never want to use this name again, release it to the pool for everybody else”. Maybe I should have emphasized the you in “you will never, ever again in the history of the universe, be able to publish a snap under the … name”.