well, the reference is still the README.md from the master tree of the above branch …
For my personal projects i usually use our linux-generic tree directly, but that is because I only enabled boards yet that are in the list of the ~500 supported boards this kernel can run on by default (by simply pointing to the right devicetree).
all commercial boards i have seen yet were either to new to be used by this kernel (based on what mainline supports at the given version) and using something around 3.4 or 3.10 (i.e. the 96boards devices …) for their BSP trees … @ppisati is really the person to talk about any other mandatory things than the sample-kernels stuff above but i think this is still our authoritative place (and i dont see why it would be outdated), it should use the apparmor patchsets as they are distributed with the 16.04.3 isos (which is our minimal base for this set AFAIK)
I only said may work with the latest versions of overlayfs. It would have to be thoroughly tested and verified because there are definitely issues with overlayfs and LSMs still. It depends on how they are used. It is known that early versions of overlayfs don’t work at all with the LSMs. It is unknown (to me) to what extent intermediate versions of overlayfs will work or not work and how difficult cherrypicking relevant overlayfs patches to any earlier versions would be.
The kernels there do not receive any routine security maintenance nor bug fixing, and their sole purpose is to let a user evaluate ubuntu core on their target hardware (as it is clearly stated in the DISCLAIMER section) - i usually push updates if something breaks or when someone ask to, and i’ll do it now to incoporate the new AA in 16.04.3 - but if a user require proper stable support, he should come talk to us.
With regards to the kernel configs, these are the options that the kernel plugin check at the moment: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/kernel.py - look at the “required_*” arrays. While the delta of patches on top of each branch is solely composed of AA code and config tweaks.
This sounds like a potential solution to an issue I reported about a month ago (Building node extension modules at run-time). In short it related to the fact that certain files inte the $SNAP/usr/lib/x86_64-linux-gnu directory referes unaccessable files in the /usr/lib/x86_64-linux-gnu directory:
That would be great news. Is there an expected time frame. I realize nothing is set, but an estimate in months. Also is there a suggested workaround?
Thank you @ogra
@wnmmihha Unlike @ogra stated, this feature can actually help fixing the problem for you as you’ll be able to redefine what /usr/lib/x86_64-linux-gnu means.
As for the classic snaps improvements, I suggest keeping an eye on that topic and subscribing to it. The changes are already in progress.
There are a lot of PRs in flight that are contributing to the building blocks of layouts now.
From the top of my head I still need to implement symlinks (requires for content interface improvements but actually free to reuse for layouts) and that’s about it. I have a hell lot of tests to write (integration tests, unit tests are written alongside each function added or changed.
I don’t know how we’re looking like for 2.30 (AFAIK it will be branched early next week) but if not 2.30 then 2.31 looks very realistic.
With everyone in the team back from holidays it’s due time for some progress updates. A few things have landed and some proposed we are quite close to getting everything to click and work together. Let’s see what that is:
Parsing layout sections in snap.yaml [done]
Creating mount destination on demand (for directories) [done]
Creating mount destination on demand (for files) [under review: 4452]
Creating symlinks on demand [under review: 4452]
Planning and executing mimic plan [done]
Creating writable spaces using mimic [under review: 4452]
Using layout definitions [todo]
The last element needs some security discussion as it will likely be just copying stuff from the layout definition into the existing mount profiles. What is new (complex) is writing apparmor rules that allow it to operate without opening super wide mount permissions anywhere.
The under review PR will be expanded to cover symlinks and I’ll push the update for that early tomorrow. EDIT: The PR now covers everything needed for layouts, content interface generalization, themes etc.
I will now merge / rebase https://github.com/snapcore/snapd/pull/4068 because it brings in the new mechanic for “spooling” entries into one directory. After that we only need using layout definitions from the list above. This will simply take the layout yaml definition and add it to the mount profile of a snap, taking advantage of all the mechanism added here.
The tip of my review is https://github.com/snapcore/snapd/pull/4452 which is small but contains useful new logic and tests for effectively all of layouts. The rest is as Jamie said above, a policy question as to what is allowed where.
4452 can be merged this week. With some luck so can 4068 as it had some reviews already. This leaves next week for working on layout plumbing/integration tests, with the assumption that the policy is decided separately (policy as to what is allowed). I think we can realistically look at merging layouts (even if restricted by policy) just after the sprint next week when key participants to discuss the policy question are back.
Another small update. I chopped the PR that has grown since I opened it (I added lots of unit tests that made it “scary” to review). Four small prerequisite branches have landed (mainly simple fixes and new test helpers). There are two PRs pending review now but both are blocked on Fedora infrastructure issue that should be resolved shortly, please have a look:
After those I have two more branches: one that adds a spread test and another that adds a whole swarm of carefully documented unit tests for all kinds of success and failure scenarios that may arise.
After this lands I’d like to return to https://github.com/snapcore/snapd/pull/4068 which will directly benefit from this work (it will, among other things enable plug-in snaps to work correctly and will open the work for themes for @jamesh). In parallel I’m preparing a small RFC branch that populates mount profiles with everything from snap layout data.
The update this week i smaller. I was plagued by some issues and this week seems to start with similar vein but I hope to land the outstanding PRs and open a PR that will bridge the layout definition with the mount profile mechanism. This will allow us to write first test snaps that use layouts for real to explore what’s missing.
Note that this doesn’t mean things work just yet, the apparmor policy won’t allow any layout to be constructed in practice. My plan is to work on this next week when @jdstrand returns from a sprint. Meanwhile I’m still blocked by https://github.com/snapcore/snapd/pull/4471 - please review it if you can.
Oh, and on the same vein I realized that the logic that can poke writable holes dones’t work for the root filesystem (and probably wont work immediately). I’m thinking about possible ways to support that.
We should not allow specifying ‘nobody’ or ‘nogroup’. This user (and group) is only meant to be used by NFS for assigning ownership to unmapped users. It is a common security mistake to misappropriate this user and group for other things. If this is only meant for demo purposes, please use ‘someuser’ or ‘somegroup’.
Besides, the user and group feature in layouts isn’t going to be useful until we have proper uid/gid support in snapd since snaps will find themselves in the awkward position of having files not owned by root or the calling user, and won’t be able to chown/setuid/setgid to these users, may have file access issues (apparmor owner match) or capability denials (dac_read_search, dac_override).
For now, yes. When we have uid/gid support in snapd, we can happily expand this to the users that the snap is allowed to use.
That doesn’t mean you have to rip out all the uid/gid code for layouts-- continue to use it for root:root. You could even leave the yaml exposed (but only allow root:root for now) if you don’t advertise it. I’ll leave that up to you (though, it seems possible the yaml might change when uid/gid support lands, so maybe it is best to not expose the yaml at this time).
