If you are reading this you have found my work queue. This is a public place where I am storing the high-level goals that I pursue as a part of my work on snapd.
The list is explicitly prioritised, with the highest priority items first. Higher priority items don’t always starve lower priority items, this is just my internal guidance. I will, to the best of my abilities, try to do more than one item in parallel, whenever that feels appropriate.
If you are a stakeholder and depend on my work you can use this to estimate overall completion and how it relates to my other tasks.
Assisting in core18 transition
Currently some interfaces are “implicitly” defined to show up on the core snap. Once the core snap itself gets deprecated and multiple base snaps (like core18 and later on core16) are present the implicit interfaces can no longer be associated with core alone. The plan is to move them to a virtual system snap and adjust some of the logic to know that it is really virtual.
Update: this is progressing nicely, I plan to make one more change to translate core to snapd on explicit connect/disconnect operations and hand the patch to mvo for integration.
Some PRs:
Progress: just started
Estimated: ~day-or-two
Fixing known bugs in layouts to get them out of experimental stage
Layouts still have two known issues: trespassing on host filesystem and lack of apparmor rules for earlier mimic construction.
Trespassing occurs when a change inside per-snap mount namespace unexpectedly leaks into the host filesystem. This is visible as one of three cases: an empty file, an empty directory or a symlink. The empty objects are used as mount points inside the per-snap mount namespace. While the actual mount is not visible on the host the presence of those files is undesirable.
We had several attempts at fixing it with one needed refactoring to avoid global variables and some ugly code. I have landed several prerequisite functions and need to push on the final branch that ties it all together.
The generalised mimic profile is now a PR: https://github.com/snapcore/snapd/pull/5395
Progress: fair
Estimate: ~week
The lack of apparmor rules for earlier mimic construction occurs when a layout or content connection grants rules to create a writable mimic at a path like /usr/lib/x86_64/foo/something.so but part of the traversed path is missing and the writable mimic needs to be constructed at an earlier stage, such as /usr/lib/x86_64/foo.
We had an earlier attempt at fixing it but it uncovered a bug in apparmor_parser. An improved helper function is currently under review. After the helper lands I will use it to generate different apparmor profiles for writable mimics.
Progress: almost done
Estimate: ~week
Assisting with Fedora 29 base snap
We’re going to Flock in August and we’d like to bring a working base snap showing a Fedora 29 base snap and some simple applications running on top.
Generalising support for per-user mount namespaces
Snapd now supports a limited form of per-snap, per-user mount namespaces. Those are currently not persistent and cannot be updated with the snap-update-ns mechanism. Generalising that would allow us to offer content and layout features that use $SNAP_USER_DATA and $SNAP_USER_COMMON. This is not very hard but involves a subtle part of the application startup process. It has some intersection with the problem of enumerating users as invalidation and refreshes now need to be able to do that.
Progress: some branches in progress but only for the persistence and configuration part, invalidation and update-from-snapd not done yet
Estimate: ~month
Fixing data migration issue on refresh while applications are running
When a snap is refreshed a copy of the per-revision data (in $SNAP_DATA and $SNAP_USER_DATA is copied over to the refreshed-to revision. While this happens an application may be mutating that data, keeping opened file descriptors, etc. In addition apparmor profiles are updated instantly (applying to existing processes) to restrict write access to the refreshed-from revision. This causes subtle issues that go away when the application is restarted.
There was some discussion on how to fix this but it is a non-trivial topic.
Progress: none
Estimate: unknown, needs research
Look into missing profiles
Some people are reporting that certain snaps don’t start because the profile is not loaded. I need to look at the forum and IRC history to collect more data.
Look into issues on mainline kernel
Some people are reporting that snap-confine doesn’t work on ubuntu with a mainline kernel (using the apparently popular UKUU tool). I plan to run a mainline kernel and see what happens.
Thread: Custom kernel error on readlinkat() in mount namespace
