Our current /etc (and /var) on an ubuntu-core system is a bit of a mix between bits that are writeable and bits that are read-only. The default is read-only and only selected bits are bind-mounted into read-only locations. This causes quite a few problems, e.g. if selected files in /etc are mounted “rw” but /etc itself is not writable the usual atomic rename pattern to update files does not work anymore.
The proposal is therefore:
go over /etc and remove all files that are not strictly needed
patch all software that uses files in /etc so that it has build-in defaults instead of a default configuration file
The task may seem daunting but a) core is relatively small b) there is a consensus to move towards a stateless system so upstreams are likely to accept patches c) there was e.g. clearlinux that also tried this with some success and we can probably leverage patches.
I think we should make this a goal for ubuntu-core-18. WDYT?
along with this we should do a deep review of our installed package set, not everything we ship in core-16 is needed anymore and should be cleaned up in core-18.
we still pull in default debian dependencies for features we potentially dont use, we should look at the purpose of each shipped app and reduce the deps to the minimum focused on the purpose only.
One thing that might be problematic is snaps using interfaces that expose the writable paths. Two situations that come to mind are:
the parent dir of a file that is allowed by interface policy stays writable (ie, the parent dir is in writable-paths), but the file is removed and snaps fail
a file that is list in writable-paths (ie, the file, not its parent dir) is removed and therefore the entry must be removed from writable-paths (nothing to make writable). Snaps will fail if this file is allowed by interface policy because the snap can’t create it cause the parent dir is readonly.
But really any situation where interface policy allows the write but the result of the cleanups results in the access going read only. As a result, part of this exercise should include:
grepping the apparmor policy for writes to files in /etc
seeing if on core those are in writable-paths
determine what would happen if the file was removed or it goes read-only
Sounds like a good plan, and we need to keep an eye on these changes while we evaluate the base snap modifications that are being discussed, since there may be related points to be addressed together.
It would be good to be more clear about the “patch all software” note. This is about core, specifically. We’re not expecting people to change every piece of software to adapt to a new reality, and in fact we’re planning to introduce features very soon that will enable people to observe whatever content in /etc they’d like to see there, as far as the snap itself is concerned. The change proposed here actually helps with that.
we also still have a bunch of packages that use the systemd generators to generate units, we should make sure these packages ship native units instead if we patch the debs anyway.
