This is a summary of some of the snapd/snapcraft issues that are important for to the Ubuntu Desktop team in order to provide the best possible snap experience. I’ll update this post as more things come up and things are fixed. If I’ve missed something important, please tell me
Snapped applications should use the desktop’s theme.
Currently snapcraft-desktop-helpers cloud parts stage the standard Ubuntu theme into your package. That gives decent integration up until the point a user changes the theme.
Snaps should be able to access a theme that is (a) visually compatible with the user’s desktop and compatible with the toolkit version the application is using. The themes installed on the base system won’t necessarily meet these requirements, so it probably means we need snap packaged themes.
At a minimum, we want to support the commonly used themes, and ideally allow third parties to provide versions of their own themes for use with snaps. Zygmut suggested this might involve the use of not-yet-implemented “content snaps”.
The snapcraft-desktop-helpers cloud part ships the Ubuntu font with a snap, which is fine provided the font covers your spoken language. If you require another font to display readable text, you’re out of luck.
Making the system fonts available to strict confined apps might be the best way solve this. We don’t have the same compatibility concerns as for themes, since font formats are relatively static. Would we also need to make some of the fontconfig configuration visible too?
Status: core snap PR created. Still need to look at the snapd side.
Allow graphical installation/removal of snaps without a store account
From the command line, there is a low barrier to entry for people wanting to try a snap: if you’ve got sudo access, you can start installing and removing snaps right away. This puts them on par with installing .deb packages from the archive.
If the user is using gnome-software instead though, they will need to create an Ubuntu One account and sign in before they can start installing or removing snaps. Ideally the user could prove their administator credentials in the same way they do for installing .deb packages.
The simplest solution would be to add polkit authorisation support, which is used for most other graphical administration tasks:
Status: Basic polkit support for /v2/login API has landed in master. Expanding this to handle package install/removal is under review.
Support xdg-desktop-portal
xdg-desktop-portal is a D-Bus service that grew out of the flatpak project as a way to give confined applications controlled access to various desktop services. This includes, but is not limited to:
opening or saving user-selected files from outside the sandbox via trusted file pickers,
opening URLs in the user’s web browser (similar to our custom xdg-open in the core snap)
printing documents
accessing the user’s network proxy configuration
Inhibiting the screen saver for things like media playback.
Modern versions of GTK have support for xdg-desktop-portal baked in, and there is a QPA plugin to let Qt applications use it too. So I think it makes more sense to adopt this technology for use by snaps on the desktop rather than try to build an equivalent and try and get buy-in from the toolkit developers.
Getting this working properly will require some changes to the way snap-confine works though: we most likely need to create separate mount namespaces for each user who tries to run the snapped application, and ensure that the mount namespace is destroyed at the termination of the desktop session. This has been discussed in the following thread:
Snapcraft should make it easier to build non-relocatable applications
Many applications embed their install prefix into configuration files or the executable itself. This should be relatively easy to support, since an app can assume it is available at /snap/$package_name/current.
However, Snapcraft’s autotools plugin doesn’t make it easy to bake this prefix into an app. At first, it looked like the install-via: prefix option would help but it ends up baking in the temporary install directory of the build system instead.
We probably want to instead do something like:
./configure --prefix=/snap/$package_name/current
make
make install prefix=$SNAPCRAFT_PART_INSTALL
Let developers build snaps with the gnome-builder IDE
I made a first stab at implementing a Snapcraft plugin for gnome-builder, but when trying to upstream it I was asked to make a few changes that are difficult to implement with vanilla snapcraft.
The primary request was to let gnome-builder run the underlying build system itself, and build from the primary copy of the source. This is to allow (a) programmatic manipulation of the project (e.g. updating a target when a new source file is added), and (b) allow incremental recompilation when the user makes a change rather than starting the build from scratch.
I made a proposal about what I’d need from Snapcraft to implement this, but haven’t had a response so far:
Provide translated package summaries and descriptions
Currently package metadata is not translated, so package information appears in English no matter what the user’s native language is. If an app developer wants to make their package available to a global audience, they should be able to provide the summary and description in multiple languages.
Snapd should be able to access these translations (where ever they happen to end up being stored) and provide them to API users. @robert.ancell has made a first step of getting the snapd-glib library to send an Accept-Language HTTP request header, so when snapd gains support for translated metadata, it should work with gnome-software.
This is interesting and you’re right. I don’t think a simplistic implementation that is a per-user, per-snap mount namespace will work, because we’ll break certain use cases with daemons in the snap (ie, which run as root) and cli/gui commands (which usually won’t). I think we’d want to explore where a portion of the mount namespace is shared across any uid invocation, but certain desktop-specific directories are uid-specific with appropriate mount options.
Is this just for the private /tmp, or is there more to this? Everything else looks like it would be the same if the namespace is reconstructed.
I suppose one option is to continue creating the persistent per-snap mount namespaces, but rather than using it directly for the confined app, clone it again and add the per-user mounts. That would also solve the life cycle issues, since this second namespace would go away with the application, so there would be no outstanding bind mounts referencing the FUSE daemon.
Sorry about item 6. I just took a look and the date and I was in the middle of my holidays when that came in, that said, I did follow up in there. Most things are doable and we can certainly get something going but I would like to have a bit more discussion about this main part and the focus of gnome builder and what types of projects it would build.
About 5, doesn’t the new layouts functionality solve this problem? We would need to extend snapcraft to make use of this and make plugins smarter into reporting what layout they would need after building though, it should still solve this problem.
I don’t think layouts make a difference (if this is the feature I think you’re talking about). This isn’t about executables needing to appear under /usr (or wherever): they just need to appear at the location they were built to appear at. Currently neither of the options for the autotools plugin satisfy that:
With install-via: destdir, the project is configured with --prefix="", so at build time the executable thinks it will go in /bin.
With install-via: prefix, the executable thinks it will be installed to $snapcraft_projectdir/parts/$partname/install/bin (encoding whatever directory the Snapcraft project was built from).
There’s no problem with the snap’s files appearing under /snap/$snapname/current: we just need the project to be built in such a way that it knows that’s where it will be installed.
@jamesh
I’d also like to propose to let desktop application access the camera, audio etc. by default.
I do not consider it as user friendly to have to connect the plugs after installation using the terminal,
Use case
User installs app over software center, when he starts the app, he has to open a terminal and type some command to connect the camera to the app.
@Gocarlos
I think there are legitimate concerns about giving untrusted apps free reign to access your microphone or webcam. With that said, I agree that requiring the user to connect up interfaces is probably not great either.
Ideally the user should be prompted when the app tries to use the device. That means the app is already running, which is too late to start fiddling with its AppArmor confinement.
There is some support in xdg-desktop-portal for displaying an access control dialog box for device access, but it doesn’t seem to actually implement the actual device mediation. Instead, it sounds like the idea is for a PulseAudio module to call into xdg-desktop-portal to decide whether to give a client microphone access.
I’m not sure if there is any daemon in place to mediate access to the camera yet, so that’s something to investigate. We had such a service on Ubuntu Phone, so if there is no equivalent for GNOME yet, perhaps that could be a starting point.
I agree that the user should know that the webcam and microphone are used by app xyz.
I think the easiest way to solve this problem is to declare the plugs as is done now and to use a pop up before using the app.
I think that it could be easily solved by showing the user a pop up with the permissions before the app starts (after the user typed the command or selected the GUI icon). If the user does not accept this, the developer can set what is behavior.
Doing some stuff (mediation) when the app is already running will be eventually error prone.
I think that if this is not implemented in some near future, developers will still use debs to get work done instead of messing around with permissions (if they are not straight forward)
Dealing with confinement is always going to cause some pain. But in exchange, we lower the barriers to getting your code out to users.
If you don’t want to deal with confinement, there is always the option of classic mode snaps: that gives you similar access to the system you’d get with by distributing as deb packages. The downside there is the requirement for manual review to release on the store.
As for when the user should be prompted for device access, I think there is a good argument to do it as close to the actual use as possible. If the user clicks a button to take a picture and gets presented with a dialog asking if they want to grant access to the webcam, they have a lot more context to make the decision than if they are asked before they’ve even run the program.
I was referring to “There’s no problem with the snap’s files appearing under /snap/$snapname/current: we just need the project to be built in such a way that it knows that’s where it will be installed.” of course.
At the time where most of the work took place, /snap/<snap-name>/current wasn’t a set in stone location for snaps (which is one of the reasons for $SNAP to ever come to be). Today that is different so we are much more willing to make that the prefix in the plugins be /snap/<snap-name>/current. The drawbacks here is that if you build a runnable in a part that would be reused in another part to continue a build you may run into problems whilst by using --prefix= some projects are smart enough to build in relocatable mode. The other drawback is that changing the snap-name means you need to rebuild.
So, that makes me think that hardcoding the prefix would be something you choose to do for the sake of backwards compatibility.
It is definitely for backward compatibility: if an application has been written to be relocatable, then it isn’t needed. If the app is not relocatable, then this makes the difference between simply having to write a snapcraft.yaml file and digging in to modify the code.
And I don’t think I’ve ever encountered a package where building with a blank prefix caused them to suddenly build in a relocatable mode: most apps that are relocatable will act as such no matter what prefix you build them with.
As for a concrete example of what we’re dealing with, consider GNOME’s image viewer. It uses a fairly common pattern to configure internationalisation:
… which in turn references a preprocessor macro defined in the Makefile:
… leading to the prefix being baked into the executable. If you then move the compiled application and its data files to another location it will no longer be able to find its message catalogs, so only display in English. So none of the modes for Snapcraft’s autotools plugin would result in working i18n.
The forum doesn’t seem to let me edit the initial post any more for some reason, so here is an update on the progress so far:
Polkit support was merged and cherry picked into the 2.28 branch, so once that release is available it will no longer be necessary to create an Ubuntu One account to install snaps. Like the command line, you will require a store account for more advanced operations like purchasing paid snaps.
Host font support was merged to master, and should make it into the 2.29 release. This should be available automatically to all snaps using the new desktop interface, exposing host system fonts from /usr/share/fonts and /usr/local/share/fonts to the sandbox, along with the associated fontconfig cache files.
My own personal goals going forward are to try and build a solution to the themeing problem, and have another run at portals.
A few more issues for the desktop team priority list:
Recover from store login password changes
After logging in to the store with Ubuntu One credentials, snapd stores a macaroon to authenticate future store API requests. When the macaroon expires, snapd will contact the SSO service to refresh that macaroon. If the user changes their password, SSO will refuse to refresh the macaroon.
At present, snapd returns a generic “Internal Server Error” for this failure, which limits how smart a graphical application can be in prompting the user for the new credentials.
Set default browser (or email client, file type handler, etc)
While snapped applications can advertise URI schemes or mime types they are capable of handling, they can not alter the user’s default application settings. Long term, this is probably a job for xdg-desktop-portal, since (a) the default settings are stored centrally in a single file, and (b) confined apps probably shouldn’t be able to alter these settings without user approval.
Is it worth producing an interim unsafe interface that lets the apps update the settings anyway?
It’s a new year, so it’s probably time for an update on this list. These are issues that I’ve either been working on recently, will be working on in the near future, or am aware of. If
Snapped applications should match the desktop’s theme
The plan is still to package themes as snaps, as the themes on the host system are not guaranteed to be compatible with the libraries available in the sandbox. We came up with a basic sketch for how this would work at the Hague sprint (extending the content interface to allow a snap to mount content from multiple sources at once), but it still needs to be implemented.
Support xdg-desktop-portal/xdg-document-portal
This is desirable because it increases the capabilities of desktop applications that don’t plug the home interface, among other things: the application can be given the ability to open or save files in any location the user can access, without being given access to any locations the user hasn’t explicitly granted access to.
One component of this work was to add support for “user mounts” – that is bind mounts in the sandbox mount namespace that are specific to the current user. The main use case for this was xdg-document-portal, which relies on a specific bind mount to make files available to the container securely. There is a pull request for this feature, but it is as yet unmerged.
I also started the process of trying to upstream support for detecting snaps in xdg-desktop-portal. They are receptive to adding support, but would prefer to handle it via an in-development “app container socket” feature for dbus-daemon. A discussion was started around supporting this in the way we set up dbus access for confined apps, but it will require implementation work.
Speed up first launch of desktop apps
Snaps using the snapcraft-desktop-helpers desktop-launch script had noticeable delays on first start. I identified some of the more costly actions and looked at solutions that allow some of that work to be moved from first run to package build time.
Parts of that work have landed in snapcraft-desktop-helpers, and changes to the GNOME platform snap will let some applications take advantage of the speed ups right away. However, we don’t have a good solution for apps that bundle their own GTK or Qt. This will probably need the Snapcraft extended scriptlets feature to be implemented and merged.
There are a number of improvements in the works for gnome-software’s snap support, some of which require corresponding snapd changes. I’ll break this out into separate issues soon.
