Snapd normally stops trying to reexec when the current host distribution is not
in the list of supported ones. However, allow reexec to be attempt if
SNAP_REEXEC is explicitly set to a truthy value in the environment. This enables
testing of the reexec functionality on a wider range of distributions.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Add helpers for setting up environment for running in FIPS mode when reexecd
from the snapd snap.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Executable files from snapd snap do not need anymore to have
the dynamic linker and library paths to be overridden. But
the ones from core snap still need it.
Simplify the check for reexec being enabled in the system.
Thanks to @alfonsosanchezbeato.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Expose another helper for asserting whether reexec is enabled for a given
distribution we're running on.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Distros like openSUSE Tumbleweed or Fedora use /usr/libexec/snapd. Update the
test to account for the correct path.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* snapdtool: check for binary existance in InternalToolPath()
The current version of `InternalToolPath()` does not actually
checks in all cases if the binary is actually there. Historically
this was not a problem but with recent snapd releases we have
the internal tool `apparmor_parser` that is only available in
the `snapd` snap but not in the `core` snap. This means that
on systems that have the snapd deb and only core `InternalToolPath`
may return `/snap/core/123/usr/lib/snapd/apparmor_parser` even
if this tool in not available inside the core snap.
This commit fixes this by checking if the actual executable
is available.
* snapdtool: add test for non-executable internal tool path
* snapdtool: simplify InternalToolPath() (thanks to Samuele)
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>
this will be useful to determine supported assertion max formats for snapd/core
and kernel snaps that are used to build an image
to do this we split out snapdtool.ParseInfoFile
The info file is essentially always implicit here, so we can just provide the
dir. Thanks to Samuele for pointing this out.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Also set a new key, SNAPD_APPARMOR_REEXEC, to 0 for now, since this key will be
used shortly with the new apparmor vendoring inside the snapd snap.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
