We previously wouldn't fail on verification for snaps that used new top-level
directories, and would fail at runtime, which produces a very unhelpful message.
Also adjust some test yamls in interfaces/mount tests, which are not valid as
they are for new top-level directories in /.
Finally, add an additional unit test for the test case with LP #1831010 that is
already covered by spread tests, but not yet by unit tests.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Take into account the host's cgroup version when reporting mount backend
features.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
The directory synchronization code grew out of the desire to have a set
of files described by a glob and short, in-memory contents be reflected
to the disk in an efficient and predictable way.
Recently this code has started to be used to install icon themes shipped
by snaps. This means it may be used to coerce snapd to read arbitrary
amount of data into memory.
This address this issue by generalizing the directory sync APIs to take
an interface instead of a concrete representation of the desired file.
There are now three concrete implementations, one that keeps the content
in memory, just like before, called MemoryBlob and two new ones:
FileReference and FileContentReference. Those both refer to an existing
file for content, opening up the possibility to refer to large files.
They only differ in the treatment of file mode, either mirroring the
mode of the file being referred or using a fixed mode, respectively.
Behind the scenes the EnsureFileState function will no longer read all
of the file into memory. Instead if will use FileReference to stream it,
chunk by chunk, in an attempt to see if the file is identical to what we
expected.
On top of that, if the file is not the same and the caller has provided
a FileReference or FileContentReference, the logic that writes a new
file and replaces the original is also using streaming, again saving a
in-memory copy.
This way we can now process files of arbitrary size using fixed amount
of memory. This involves the new icon wrapper which has been switched to
use FileContentReference.
The patch contains some verbose automatic changes around the code using
maps of FileState structure to replace them with maps of FileState
interface instead.
Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
When a snap is removed each security backend is asked to remove the
security profiles associated with the snap in question. For the mount
backend that would just remove the desired mount namespace profile.
While this part worked correctly there was more to be done. The system
may still have the preserved mount namespace as well as the actual
applied (current) mount profiles that exist therein.
In a case where a snap was installed but the installation failed because
of a hook issue, the system would be left in a state where an existing
mount namespace would be left behind.
Related-To: https://bugs.launchpad.net/snapd/+bug/1808821
Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
The per-snap lock routines were defined in the mount interface package
long ago, when they were still used there. They are only referenced from
snap-update-ns now so it's sensible to move them.
I will need the same routine in overlord/snapstate so I picked
snap/snaplock (due to the dependency on osutil) as the appropriate
location.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Establish the necessary mappings for parallel installed snaps by updating the
mount profile of the snap. The change adds the following bind
mounts:
- /snap/foo_bar -> /snap/foo
- /var/snap/foo_bar -> /var/snap/foo
The mounts have `x-snapd.origin=overname` in the mount profile. 'Overname' mounts are applied before any other mounts.
In preparation for parallel installation of snaps, introduce the necessary
rename of snap.Info.Name() to snap.Info.InstanceName(). The change is benign and
will make subsequent parallel installs reviews easier and smaller.
Leave TODO notes about possible issues with parallel installation where
possible.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* many: add "snap debug sandbox" and needed bits
This patch adds a way to inspect the features of the sandbox from a new
hidden, debugging command. The command shows a set of tags for each of
the security backends that are in use.
Having access to this command helps in two ways:
First of all, this is far more comprehensive and informative than the
very dry "partial" vs "full" output of "snap debug confinement". Snapd
offers a wide range of confinement technologies when used on a mainline
kernel and this should be celebrated.
Second of all having this allows us to write more precise tests. If a
test needs to be skipped because a specific thing is absent can now be
codified directly. This will allow both Debian and openSUSE to run far
more confinement-specific tests than we currently do simply because
"partial" apparmor is reported. Mainline kernel is very close to full
apparmor patch used by Ubuntu and the remaining differences don't apply
to many existing tests.
Technically this patch adds the key "sandbox", defined as a map of lists
of strings, to the sysinfo API and uses it in the new hidden command.
Each of the security backends can now optionally offer sandbox tags that
are associated with the backend name in the said map.
* interfaces: namespace kernel features with "kernel:"
This arrangement will allow the seccomp and apparmor backends to report
additional sandbox feature tags without risking any clash with kernel
reported things.
* interfaces/seccomp: return at least one sandbox tag from seccomp
In case the kernel doesn't advertise seccomp kernel features we don't
want to make the seccomp backend appear as missing or unused. Add an
explicitly managed tag to achieve that.
* interfaces/apparmor: dbus mediates more than just bus names
* many: rename sandbox tags to sandbox features
* cmd/snap: add support for "sandbox-features --required=..."
This patch allows using the sandbox-features command for simple
scripting, especially in spread tests, where we could check if a given
sandbox feature is present before checking confinement is effective.
* tests: fix and expand sandbox-features tests
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This patch changes various mount related code to use functions that
access or create various x-snapd.foo mount options. This should lessen
the chance of any typo sneaking past code reviews.
The test suite is also improved to be more consistent and complete with
regards to code coverage.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
