Thanks for the request. Please bear with us since this is one of the first requests for a base snap.
According to Process for reviewing base snaps, the name of this snap, freedesktop-sdk-runtime-19-08, is valid (though the examples suggest freedesktop-sdk-runtime-1908, I don’t believe that is a blocker). As such, this seems a reasonable candidate. Since this is one of the first community base snaps, I’m going to ask @pedronis to review Process for reviewing base snaps and this snap to ensure we have captured all the requirements.
In terms of vetting, Valentin appears to be a member of freedesktop-sdk which IMO is suitable for this base snap; @advocacy, can you verify this and perform any additional vetting (eg, as we might do for globally connected content snaps or classic-- since a base snap places a lot of implied trust by consumers in the provider’s publisher). @pedronis, is there any vetting criteria you’d like to see met? Perhaps a collaborators feature or something more official than Valentin’s personal email address?
When this is all done, I’ll generalize the requirements and update our processes accordingly.
@valentind - thanks again for your snap and working with us
Sorry it took me a while to get back to this, not lack of interest or support, but bad timing with vacation and planning events…
Yes, 1908, no hyphen, would be more typical.
Related to this, it’s important to remember that what is being setup here is a contract between the base and the snaps using it: after a base snap is in stable any backward incompatible changes to API/ABI or removing any file that would have been accessible given the default apparmor template or relevant interface ones would be a break of that contract.
A base runs with as much confinement as the snaps using it, OTOH for example libraries related to networking in it could capture data and send it somewhere else. This means, I would think, some level of publisher vetting similar to classic would be appropriate, I would say it’s much preferable if a base is maintained by a community or project than an individual.
A base needs to contain empty directories for anything that snap-confine doesn’t create but mounts over.
I would imagine that a base might contain files with permissions etc that are outside what we allow for app snaps, that will need exceptions, special considerations.
If the base needs to expose files that are not allowed by the base template, hopefully not, we need to think what to do.
That’s the first set of things that came to my mind.
Also @valentind, given that we don’t have and didn’t expect many bases ATM so we punted on non ad hoc approach, I think you’ll have to discuss with @sergiusens how to make sure snapcraft knows how to get appropriate build images corresponding to the base.
This should not block experimentation or the initial build up though. What is the timeline for this? I would like to take the opportunity to work on documentation while go through this procedure.
I performed a review of revision 12 of the snap and can say that:
the permissions/ownership of the files in the snap are fine
the following are missing from the snap that snap-confine won’t mkdir (from sc_populate_mount_ns() in mount_support.c)
empty mnt (optional, but best to include)
empty var/lib/extrausers (optional)
there is a lot in the base that is not represented in the default template or interfaces. Eg (listing just a few representative items):
kerberos binaries
usr/bin/lz*
usr/bin/sndfile-*
usr/bin/tiff*
…
I also noted that the snap has a lot in /etc which is just going to be mounted over.
It isn’t clear to me if everything in the snap is expected in the runtime (I suspect not since it also includes things like pam and mkfs utilities) so it seems that the snap needs to be cleaned up to only ship the things that it requires (this would also make it much smaller). Once that is done, we can revisit what is needed to proceed. @pedronis, can you also weigh in?
I did not try to publish yet the SDK part which is needed for building against. I have seen that the images used were hard coded. The first goal however is to be able to provide applications built with BuildStream. So this is not needed to use snapcraft to build application. But I think we should we should get snapcraft to be able to build on top of the Freedesktop SDK.
I will add those directories. Is there documentation (or commented source code) related to those? Are we suppose to read something from there?
/etc being mounted over is actually a tricky issue. One issue with it for example is that fontconfig configuration is taken from the system, but system fonts do not seem to be mounted.
I expect we will have other issues like that. Flatpak selectively binds files like /etc/resolv.conf, so we never had to worry about where the configuration files go.
I am planning to change the path to /usr/etc for files that should be read from the Freedesktop SDK runtime rather than the system. Though for fontconfig, I need to get a file from /etc from flatpak that tells me where the system fonts have been mounted, so I am expecting some work there.
Would file from /usr/bin not be allowed to run with snap-confine? I have already noticed that bash has some issue, so I added dash. But I thought this was only needed at startup. Running lzip for example seem to work. Is snap-confine relaxed when running --shell?
I suppose for pam and mkfs was because we need the libraries and we did not filter out the binaries. We will fix that.
I suspect you can ignore the extrausers stuff. It is used by Ubuntu Core systems to allow new users to be added to a system where /etc/passwd is read only. This is only really important for a base snap that is being used to boot a system.
I don’t think it is relevant to a base snap that is purely being used as an application runtime like what you’re proposing.
For applications that plug the desktop interface, the following will be mounted in from the host system:
/usr/share/fonts
/usr/local/share/fonts
/var/cache/fontconfig
So the system fonts.conf is usually good enough, unless your fontconfig is old enough not to recognise the translation attributes/elements found on modern systems. Related to this, if you’re shipping any fonts in the above directories, they will likely be shadowed by any applications using your base.
Our current bases ship with non-empty /etc, also because they are meant for use as bootable bases for core. I’m not sure if we should enforce empty /etc for non bootable bases (bases not intended for booting) for clarity or not, or if achieving that is too annoying for the build processes of bases.
Either way given the current mechanics /etc will be ignored/mounted over. If there’s really something needed from there we have a problem.
It is hard to know if there are files needed. If there are bugs reported related to it, we will move the needed ones to /usr/etc. But most likely most of the ones mounted should be fine.
Note that if you ship them in /usr/etc, you can then use the layouts feature to put them in /etc (eg, via a bind mount) if you don’t want to modify code to use paths in /usr/etc.
Well, the thing is there is security policy that allows use of specific binaries in /usr/bin. Since the core snap doesn’t include the ones I mentioned, security rules aren’t present for allowing use of them. If you need to ship binaries in /usr/bin, /bin, etc that aren’t also present in the core snap, then we need to design a way to expose them to the snap (fyi @pedronis). That said, I’m puzzled that you said it seemed to work. How did you test this?
Yeah, I didn’t mean to imply it would be rejected but more to point out that since it has stuff, it isn’t going to be used. Clean is clearer though, so happy to update the review criteria as needed.
I have misread the documentation. It is devmode that implies dangerous.
OK, so I have made an app that contains just a script. And snap info --verbose says it has confinement on. The script only contains a call to /usr/bin/lzip -h. And it works. So obviously confinement does not disallow applications to call lzip.
