Bug report on KDE Bugzilla
I’m asking for help because Nate Graham and I don’t know what the problem is.
One can’t run snap commands in Konsole in the KDE snap session, nor can one run snaps in that session from the application menu.
STEPS TO REPRODUCE
snap install --edge --devmode plasma-desktop on a snap-enabled system.
sudo wget https://metadata.neon.kde.org/snap/plasma-snap.desktop -O /usr/share/xsessions/plasma-snap.desktop
- Log out of your current session and log into Plasma (snap)
- Press Ctrl+Alt+T
bash: snap: command not found or something like that!
One can run
snap commands in Konsole and they function as normal.
Linux/KDE Plasma: Ubuntu 18.10, core 2.36.3+git1063.bbf4a49~ubuntu16.04.1 (6148) [edge]
(available in About System)
KDE Plasma Version: master+3ffadd6 (4) [edge]
KDE Frameworks Version: 5.47.0 (27) [stable]
Qt Version: unsure
$ which snap
$ echo $PATH
Plasma snap session:
$ which snap
$ echo $PATH
@Wimpress @popey may be interested in this as I presume they helped make the Plasma snap at the snapcraft summit?
I am guessing this is because when you run commands from within the desktop environment, your shell and all processes are subject to snap confinement. One aspect of snap confinement is that a snap can’t modify other snaps, and the
snap binary isn’t present in the rootfs presented by the core snap so that’s why you can’t find it on the path.
Well it’s in devmode at the moment, but the absolute minimum of snap confinement still applies I suppose, yes. Hmm… would autoconnecting a specially created interface for desktop environments that grants wider privileges than allowed currently resolve the problem @jdstrand (since you’re the confinement expert from what I can tell)?
Running in devmode doesn’t change the rootfs that the snap is presented with.
The interface you would want to be able to manage other snaps from a desktop environment would basically be
snapd-control, which allows access to the snapd socket. This interface is highly privileged and only granted to basically snapd itself and some snaps that folks use inside a brand store. I don’t think it would be granted to a desktop environment on the public store like this.
In my humble opinion, I think a better option than granting a desktop environment snap lots of permissions in order to interact with things outside the snap environment is to instead have as much as possible live inside the snap. For example, imagine this as a graphical container (i.e. docker or lxd). You would be able to use apt inside the container, start shells, etc. but all of the file system that you use in the container (with the exception of the home folder, etc.) would be constrained to live inside the snap.
No I think you’re right that privileged access might not be a good idea (since any automatic refresh could pretty much completely take over the user’s system?) And actually there are upsides to the approach you’re suggesting - different desktop environments would have completely separate applications and defaults - when you install Plasma you won’t have GNOME apps cluttering your menus!
Having said that, it would be really good if one could use snaps inside the Plasma snap… is it possible to have a separate snapd instance running inside the snap? Perhaps with the parallel installs feature?
I don’t think parallel installs will help you (that just lets you run two separate instances of the same snap at the same time). Really what you want is to run snapd inside a snap, and for that to work (in addition to a lot of other things) you need LSM stacking which I have little experience with and don’t know if that’s supported or been looked into at all. I think this was somewhat discussed for running AppArmor with SELinux on Fedora, but that’s all I can say. @jdstrand or @zyga-snapd may know more.
What is generally needed is for snapd to grow a launcher mechanism that a shell like plasma would be allowed to use to launch applications. This would not extend to terminal emulators like konsole, which would have to remain classic for the time being.