Build drivers tree on installation so kernel modules can be found on first boot after installation (otherwise the modules would be available too late, after initial installation of the kernel has happened while seeding).
Also, make sure that the tree is not re-created when seeding, and add a spread test for kernel-modules components.
* dirs: add function to get root of drivers trees
* kernel: do not recreate drivers tree if it already exists
On installation, a drivers tree has already been copied to the data
partition. Do not re-create if found when seeding happens (note though
that on preseeding we will not find the tree and we will still create
it).
* gadget/install: create device tree on installations
Create a device tree on installation so we have it on first boot.
* o/snapstate: fix task message
* tests/nested/manual: add kernel-modules-components test
This test installs a kernel-modules component and verifies that the
shipped kernel module is installed and can be loaded.
* tests/lib: do not error out if cloud-init finished with
'recoverable error' status.
* kernel: have destination as argument when building drivers tree
We need to tackle the generic installation case as opposed to creating
the drivers tree when seeding the system. In that case the destination
tree can vary depending on installation type.
* overlord: pass kernel information to install package
so the drivers tree can be created.
* cmd/snap-bootstrap: build drivers tree on installation from initramfs
* tests: adapt to additional parameters in install.Run
* snap/naming: add ancillary method to split a full component name
into snap and component names.
* gadget/install: fix nosecboot tests
* dirs: add directory location for storing cgroup policy related flags
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: introduce cgroup policy flag for self managed device cgroup
Some snaps, due to their interfaces, are allowed to self manage the device
cgroup. In this case, the assumption was to not emit any rules at all, and
instead rely on the implicit behavior that no rules means no matching devices
and hence no device cgroup filtering. However, with introduction of a device
cgroup by default for all snaps on core24 onward, regardless of any assigned
devices, we need a separate source of information to indicate that a snap can do
self management.
The patch introduces a policy flags under /var/lib/snapd/cgroup, named
snap.<name>.device, eg.
/var/lib/snapd/cgroup/snap.docker.device, which provides a hints for
snap-confine to not set up a device cgroup filtering for apps.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: support snaps which self-manage device cgroup
Support for snaps for which policy explicitly states that the device cgroup is
self-managed. The typical use case is container like technologies. In such
scenario, there will be a device cgroup configuration file at a known location
which got generated by snapd whenever the relevant interface state changed.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: spread test
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: drop base from bases exempt from mandatory device cgroup
We have confirmed that there are no snaps which (ab)use system files and use
bare base to obtain access to devices. As such, the bare base can be dropped
form the list of bases exempt from mandatory device cgroup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: remove snap devices file when removing the snap
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: consistent use of fs.ErrNotExist
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: leave comments
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: tweak return path
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: improve managed device cgroup unit tests, verify calls to udevadm
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* NEWS: leave a note about mandatory device cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: tweak comments
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: always write the device file
Always write the device file which serves as a synchronization point between
snap-confine and the snapd udev backend.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/libsnap-confine-private: add helper for waiting for a file to show up
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: make cgroup device file mandatory
Make the per-snap /var/lib/snapd/cgroup/snap.*.device file mandatory, such that
it can be used as a synchronization point between snapd calling Setup() of
relevant security backends and the execution path in snap-confine.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-mgmt: do cleanup of /var/lib/snapd/cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* packaging: declare /var/lib/snapd/cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: use the file wait helper
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* packaging: create cgroup directory
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: update file check
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-required-or-optional: update test to verify device file
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: refactor reloading
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: move device cgroup mode selection to a helper
Extract device cgroup mode selection into a helper function.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* Apply new home directory rules to data copy
* Cleanups and adding caching of home directories
* optimizing home directory caching
* Adding tests for new home directory behavior
* improvements and enhancements to Get/SetSnapHomeDirs and tests
* snapdata_test and copydata_test fixes
* Adding tests/main/user-data-handling-homedirs/task.yaml
It also performs the verification for the root user as well as the test user present in /home
* Adding Mock functions for snapDataDirs and snapCommonDataDirs and creating unit tests
* Adding data copy between revisions test to snapd-homedirs spread test
This commit also deletes the test-snapd-sh snap files and the user-data-handling-homedirs spread test
* Change return behavior of GetSnapHomeDirs to be more in line with other functions and TestDataHomeDirs rename and fixes
* Adding unit tests and renaming GetSnapHomeDirs
* Adding unit tests and doing some cleanups
* go.sum cleanups
* cleanups, globbing expressions and root directory improvements
* more s.tempdir cleanups in unit tests, removing debug remnants
* unit test fixups, dirs.go fixups, typo fixups
* SetSnapHomeDirs optimizations, fixups and unit test improvements
* make globs only accessible via DataHomeGlobs
* fixups and conflict resolution
* comment fixup
* dirs.go fixups and improvements
* tests/main/snapd-homedirs: revision improvements and spread fix
* tests/main/snapd-homedirs: adding details section to fix static-checks
* tests/main/snapd-homedirs-vendored: fixing AppArmor tunable check
* tests/main/snapd-homedirs: reverting rev read to using snap list
This fixes issues with FHS compliant distros such as arch linux where the /snap directory is located in /var/lib/snapd/snap
* fixing comments, small dirs.go and homedirs.go improvements
* dirs/dirs.go: SeSnapHomeDirs comment fixup
* o/c/configcore: add store.access configurable to allow store access to be disable
* o/devicestate: expose store.access via the storeContextBackend
* overlord,o/storecontext: expose store.access via storecontext.storeContext
* store: use store.access to disable access to snap store when using methods store.Store
* configcore: add tests for validation of store.access
* store: test offline store functionality
* o/storecontext: add test case for StoreAccess
* store, o/c/configcore, o/storecontext: remove usage of online as valid value for store.access
* store: correct ErrStoreOffline message
* store: add unit test to check that http retries do not happen when store is offline
* store: rename isStoreOnline to checkStoreOnline for consistency
* store: remove outdated comment
* o/c/configcore: convert handleStoreAccess to be a fsOnlyHandler since it does not need state
* store: disable more instances of store network access
* overlord,o/storecontext: combine ProxyStoreer and StoreAccessQuerier into one interface
* o/devicestate: add test for storeContextBackend.StoreAccess
* store: modify Store.endpointURL to check if the store is offline
* o/storecontext: simplify TestStoreAccess test case
* store: make Store.assertionsEndpointURL return an error if the store is offline
* store: add more test cases for an offline store
* o/devicestate: remove outdated comment
* store: remove outdated comment
* store: fix outdated comments
* store: test that SnapAction returns an error when the store is offline
* store: clarify ErrStoreOffline message
* o/c/configcore: move store.access registration for more general use
* o/c/configcore, dirs: write config file for snap-repair in store.access handler
* cmd/snap-repair: consume snap repair config file to check if store access is offline
* overlord: remove accidental goimports change
* image: set root dir to temp dir for tests
* o/c/configcore: remove build flags from store.go
* store: rename checkStoreOnline to checkStoreOffline for consistency
* Revert "store: rename checkStoreOnline to checkStoreOffline for consistency"
This reverts commit dd07e487127964c417eeac11d1d954a5d1132469.
* cmd/snap-repair, o/c/configcore: use unexported repairConfig for configuring snap-repair
* o/c/configcore: fix broken test following type rename
* o/c/configcore: remove defined error to make future modifications less error-prone
* o/c/configcore: remove superfluous $
* store, o/devicestate, o/storecontext: change StoreAccess methods to StoreOffline methods that return a boolean indicator
* dirs, o/c/configcore: make sure to check fsOnlyContext for a different root dir
* cmd/snap-repair: move this change into a seperate PR
* o/c/configcore: fixup some comments
Co-authored-by: Miguel Pires <miguelpires94@gmail.com>
* o/c/configcore: add test for setting store.access on filesystem only apply
---------
Co-authored-by: Miguel Pires <miguelpires94@gmail.com>
Replace ioutil.WriteFile with os.WriteFile since the former has been
deprecated since go1.16 and simply calls the latter.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
* many: move SnapConfineAppArmorDir from dirs to sandbox/apparmor
Then when using the internal vendored AppArmor, use a different location for
SnapConfineAppArmorDir so that we don't interfere with the system installed
AppArmor.
In Ubuntu, the snapd deb includes an AppArmor profile for
/usr/lib/snapd/snap-confine that includes any profile snippets from the
hard-coded directory of /var/lib/snapd/apparmor/snap-confine. When we use the
snapd snap with the vendored AppArmor, this may contain newer features and so
would create snippets under /var/lib/snapd/apparmor/snap-confine that then may
not be supported by the system installed AppArmor. When the system installed
apparmor.service would run on boot, it would try and load the snap-confine
AppArmor profile shipped in the snapd deb, which would then try and include
these snippets generated by the newer vendored AppArmor and could fail to load
them as they would use new features not supported by the system AppArmor.
So instead, when using the vendored AppArmor, have snapd use a different
directory for the snap-confine profile snippets and then have the
snapd-generated AppArmor profiles for snap-confine reference this location
instead. This should allow to support both use-cases simultaneously.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* apparmor: add unit test that ensures that snap-confine include snippet is rewriten
* sandbox/apparmor: add unit test around setupConfCacheDirs()
* tests: add check check in snapd-snap for /v/l/snapd/apparmor/snap-confine.internal path usage
* tests: fix spread test to look at the right profiles
* i/apparmor: allow read of /usr/lib/snapd/info in snap-update-ns profile
---------
Signed-off-by: Alex Murray <alex.murray@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
* interfaces/apparmor: add permissions for per-snap directory on ubuntu-save path
* overlord/snapstate: implement support for storing data onto ubuntu-save partition on a per-snap basis
* tests/nested/core/save-data: fix shellcheck warning
* many: a bit of code cleanup
* tests/nested/core/save-data: cleanup spread test
* many: fix unit tests that were failing, add additional unit test for new handlers
* tests/main/snap-env: fix spread test after adding a new ENV variable
* overlord/snapstate: minor cleanup
* overlord/snapstate: review feedback
remove the ubuntu-save task, move some of the functionality into the backend, add unit tests
* multiple: more changes, fix unit tests
* overlord/snapstate: additional unit tests
* tests: remove check that is no longer the case for non core platforms
Snapd installs bash completion files from snaps in
`/usr/share/bash-completion/completions` which in some distributions
is a read-only filesystem.
Instead of installing them in `/usr` we can install them within
`/var/lib/snapd` which should always be writable.
Because `/var/lib/snapd/desktop` is already in `XDG_DATA_DIRS`, we can
save the files there.
Because bash-completion 2.1 and prior do not support `XDG_DATA_DIRS`,
on older distributions, the legacy path
`/usr/share/bash-completion/completions` will still be used.
This reverts commit d5eb40d189.
PR #11003 unfortunately introduced a regression on systems where the memory
cgroup was disabled because now servicestate.AllQuotas would return an error,
but we need to be able to access at least the quota group information in the
state in order to compute what options to generate services with in a few
places:
* in the ensure loop of the servicestate manager (runs all the time)
* in link-snap tasks (for snap installs/refreshes)
* in config tasks (for specifically the vitality-rank config setting)
* in discard-snap tasks (for snap removes)
So when the memory cgroup is disabled, all of the above things fail, including
catastrophically not being able to update the snapd snap (since snap refreshes
are now also broken), meaning that a user's device could not be fixed unless
they first re-enable the memory cgroup.
This will be un-reverted when we have added sufficient tests to demonstrate
that this memory cgroup check can be done in such a way without breaking this
functionality.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
