We’ve recently added a new system-files interface to the landscape-client snap to provide Landscape scripts with a writable directory on Ubuntu Core devices. I’d like to request we allow-installation of the snap.
upstream-relation: Repository & snap are both maintained by Canonical.
interfaces:
system-files (writable):
request-type: installation
reasoning: The /writablesystem-files plug provides Landscape scripts with a writable directory on Ubuntu Core devices. Since it’s broad access, it won’t be auto-connected. It could be connected via the gadget snap in cases where it’s needed.
Not a reviewer, but I have to deal with customers using it all day and this will give any user of the snap the ability to work around all snap security, confinement and measurements through random landscape scripts, pretty much making the whole snap concept moot, we are working since years to get rid of cloud-init on the devices because it allows exactly the same (and is used for this).
I have seen plenty of setups where people started altering things like generated systemd snap units, manipulate random files that should not be accessible at all etc through cloud-init which ended up having machines mis-behave or completely break to the point where they could only be factory-reset in production to recover them …
Why does landscape need full write access to the full rootfs ? This is pretty much the exact opposite of what we try to achieve with UbuntuCore…
This allows landscape-client, which is intended to be able to manage devices at scale, able to write to paths that the producer of the core image have specified as writable. These paths are typically specified as writable because they are used for configuration. Not everything in the ubuntu ecosystem has a well-defined API for configuration. The landscape-client provides a script mechanism for administrators to use to handle these types of cases and with system-files access to /writable that can be utilized for paths were pre-determined to be necessary. It also requires the producer of the snap to provide a gadget snap to connect it.
Use case:
Fleet of core based systems with firefox in an environment that requires organizational configuration. If /etc/firefox is specified in the core image as a writable path, landscape’s script feature can be used to deploy necessary changes at scale to effective lock-down the browser as needed.
There could be other ways to handle cases like this, but without support like this the script feature is pretty limited in landscape and we should make that clear to customers. These configuration situations would then need to be solved by customers for each thing they need to configure and it would need to be made clear that script support is quite limited. Right now it’s documented as a means to effectively do anything not already well defined.
After more discussion with @ogra, I’m going to -1 this myself. I think this needs to really be solved as a documentation effort in landscape to provide examples of how customers can deploy configuration snaps that use proper snap settings for everything that’s expected to be configured.