Support snap installed completion scripts

This is a very interesting problem since the supplied completion script is a *script* that runs in the user's unconfined login session. Automated reviews I don't think would be possible store side and so I think the only way to pull this off would be to somehow run the script itself confined. Confining scripts is tricky though since the 'source' command only requires 'r'ead on the file and not e'x'ecute.

OTOH, it might be worth exploring if the completion scripts were installed (or symlinked, etc) into /var/lib/snapd/bash-completion (or something), modify bash to fork/exec a helper (eg, snap-completion) that runs under strict confinement and feeds back the strings to bash. I'm not familiar with the internals of how bash performs completion, but something along these lines should provide the desired security. Of course open to other suggestions (especially from someone more knowledgeable in bash completion :).

@jdstrand:

Running the completion script confined is a good idea but does it require maybe too much infrastructure? I don't know.

For each snap which includes a completion script snapcraft could generate a trusted frontend completion script which automatically gets sourced by the users bash session. This frontend script then feeds the required completion arguments (name of requesting app, COMPWORDS, COMPCWORD, etc.) to a named fifo pipe, named "snap-completion" (as suggested) connected to a confined server process "snap-completer" which, for each completion request, spawns off another confined bash completion which runs the original completion script (backend) and writes back the response so that in the end the frotend script can recreate COMPREPLY().

Also, as mentioned on irc, some sort of sane character filtering is required to avoid malicious feedback in completion results returned to the frontend script.

Agree completely on the character filtering. Confined out of process helper as you suggested would work too. Thanks for the bug and input!

a completion hook?

@joetalbott, here's the bash completion bug I mentioned. thanks for having a look!

This also affects juju.

From a snapcraft point of view we can work on this as soon as the snapd side is ready (or hook up with someone in snapd to design the UX for this if possible).

I believe the snapd side of this has been done and landed in 2.26, would be nice if the "completer" key would be handled by snapcraft so we can start making use of this feature.

This existing pull request includes passthrough support for the completer:
https://github.com/snapcore/snapcraft/pull/1373

So I just gave this a try using snapcraft 2.33 and snapd 2.26.10 and couldn't get it to work...

As far as I can tell, the snapd package doesn't actually integrate complete.sh with the system's bash-completion mechanism.

To get it called, I've hat to create a symlink at /usr/share/bash-completion/completions/lxc pointing to /usr/lib/snapd/complete.sh

This did make something happen, in that now "lxc <tab>" hangs for a bit, doesn't complete anything, then pressing enter doesn't even run the command. Sometimes pressing enter a second time gets it to execute it, anyway, short is that things aren't working the way they should.

Attempting to track down the problem further, I found out that the following was passed to "snap run":

    snap run --command=complete lxc 63 9 8 1 "'><=;|&(: lxc lxc

Running this manually, gives me:

error: cannot find current revision for snap lxc: readlink /snap/lxc/current: no such file or directory

Which makes sense given that the snap is "lxd" and "lxc" is an alias for "lxd.lxc".

Attempting to get things to work with "lxd.lxc" rather than "lxc" also didn't go so well, possibly because the completion script inside the snap assumes "lxc".

Anyway, it appears that we need:
 - Actually integrate complete.sh with the system's bash-completion
 - Get the completion handling to work properly with aliases

Or maybe I missed something obvious somewhere and it's just my snap that's broken somehow :)

Removing the snapd-interface tag as it is being handled outside of interfaces. I believe most of this feature has already landed. John, can you comment?

The basic work has landed with the later 2.26, but need manual intervention to be picked up. 2.28 should be automagic, at which point I'll be closing this bug.

There is still no support for aliases in the completion work, but that would be a separate bug.