Some snaps need to have access to system resources outside the scope allowed by strict confinement, and are unable to do this via the available interfaces. These snaps are configured to use classic confinement and will need to be reviewed before publication in the Snap Store.
This guide shows how to enable classic confinement for a snap built with a plugin. The example project used in this guide can be found in the appropriate repository in the list below:
- autotools plugin: example
- cmake plugin: example
- go plugin: example
- when using cgo binaries
- make plugin: example
- python plugin: example
Change the confinement to classic
Starting with an existing snapcraft.yaml file, change the confinement setting to classic:
confinement: classic
This will cause the snap to be built in a way that gives it access to system resources.
Python: patch ctypes to load system libraries
If your application uses ctypes to access system libraries it will need to be bundled with a patched version of the module. To bundle ctypes, include the relevant packages in the stage-packages list of packages. For the core22 base, the packages will be the following:
stage-packages:
- libpython3.10-minimal
- libpython3.10-stdlib
Patching is done by overriding the build step to perform the build as normal, by running snapcraftctl build, then applying a patch to the staged module file with a script:
override-build: |
snapcraftctl build
$SNAPCRAFT_PROJECT_DIR/snap/local/patch-ctypes.sh
An example script and patch can be found in the example repository.
We need to run Snapcraft to build the snap with these changes to look for core Python modules that will need to be patched to refer to libraries in the base snap.
Use linters to identify problems
Snapcraft uses linters to check for issues during builds. Linters can only be specified in snaps that use the core22 base. Warnings are still reported for snaps that use older bases.
Run Snapcraft to build the snap. This may produce warnings like the following:
Lint warnings:
- classic: usr/bin/classic-example: ELF interpreter should be set to '/snap/core22/current/lib64/ld-linux-x86-64.so.2'.
- classic: usr/bin/classic-example: ELF rpath should be set to '/snap/core22/current/lib/x86_64-linux-gnu'.
If there are many warnings about libraries you can disable the library linter so that only classic linter warnings are shown. See the linters documentation for details.
Fix linter warnings by patching ELF binaries
The easiest way to handle warnings about the ELF interpreter and rpath is to let Snapcraft automatically patch the binaries using patchelf.
This is enabled by default for core20 classic snaps, and can also be enabled for
core22 classic snaps with Snapcraft 7.3 and core24 classic snaps with Snapcraft 8.3. Pass the enable-patchelf build attribute to the plugin section of the
part description:
build-attributes:
- enable-patchelf
autotools/Makefile: fix linter warnings with linker flags
In this example, the warnings about the ELF interpreter and rpath can be handled by adding options to the linker:
-Wl,-dynamic-linker=/snap/core22/current/lib64/ld-linux-x86-64.so.2-Wl,-rpath=/snap/core22/current/lib/x86_64-linux-gnu
In an autotools project, if the LDFLAGS environment variable is used, the snapcraft.yaml
file can be updated to pass these options to the autotools plugin, using the
autotools-configure-parameters keyword for projects using the core20 base or later:
plugin: autotools
source: .
autotools-configure-parameters:
- LDFLAGS="-Wl,-dynamic-linker=/snap/core22/current/lib64/ld-linux-x86-64.so.2
-Wl,-rpath=/snap/core22/current/lib/x86_64-linux-gnu"
This will only be useful for projects where the LDFLAGS variable can be used to influence the build process.
In a Makefile project, if the LDFLAGS environment variable is used, the snapcraft.yaml
file can be updated to pass these options to the make plugin, like this:
plugin: make
make-parameters:
- LDFLAGS="-Wl,-dynamic-linker=/snap/core22/current/lib64/ld-linux-x86-64.so.2 -Wl,-rpath=/snap/core22/current/lib/x86_64-linux-gnu"
This will only be useful for projects where the LDFLAGS variable can be used to influence
the build process.
go: fix linter warnings by setting link parameters
Unlike regular binaries built with gcc, Go ELF binaries may not be correctly patched using patchelf. In this case, it’s necessary to add the appropriate parameters to the linker so that the executable is created with the correct ELF interpreter and rpath. To do so, add the following #cgo parameter to your source code:
/*
#cgo LDFLAGS: -L${SRCDIR}/lib -Wl,-rpath=\$ORIGIN/lib:/snap/core22/current/lib/x86_64-linux-gnu -Wl,--disable-new-dtags -Wl,-dynamic-linker=/snap/core22/current/lib64/ld-linux-x86-64.so.2 -lzstd
#include <zstd.h>
*/
func zstdVersion() int {
return int(C.ZSTD_versionNumber())
}
func main() {
fmt.Println("libzstd version is", zstdVersion())
}
You may also need to define the following environment variables in the part’s build-environment:
parts:
golang-classic-example:
plugin: go
...
build-environment:
- CGO_ENABLED: 1
- CGO_LDFLAGS_ALLOW: ".*"
Rebuild the snap
Run Snapcraft again to rebuild the snap, consulting the Classic linter documentation to resolve further issues.
See also this article for an overview of the classic linter and a discussion of the issues involved in building snaps for classic confinement.