As reported in [1], in a case where read-only fuse (sshfs) mount
is used as a volume without specifying ro flag, the kernel fails
to remount it (when adding various flags such as nosuid and nodev),
returning EPERM.
Here's the relevant strace line:
> [pid 333966] mount("/tmp/bats-run-PRVfWc/runc.RbNv8g/bundle/mnt", "/proc/self/fd/7", 0xc0001e9164, MS_NOSUID|MS_NODEV|MS_REMOUNT|MS_BIND|MS_REC, NULL) = -1 EPERM (Operation not permitted)
I was not able to reproduce it with other read-only mounts as the source
(tried tmpfs, read-only bind mount, and an ext2 mount), so somehow this
might be specific to fuse.
The fix is to check whether the source has RDONLY flag, and retry the
remount with this flag added.
A test case (which was kind of hard to write) is added, and it fails
without the fix. Note that rootless user need to be able to ssh to
rootless@localhost in order to sshfs to work -- amend setup scripts
to make it work, and skip the test if the setup is not working.
[1] https://github.com/containers/podman/issues/12205
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Commit f30244ee1b broke the scenario of using Dockefile for
anything but making a release. This happened because it installed
native libseccomp build to a temporary directory, and so linking against
libseccomp required setting a few environment variables.
Let's fix this, and simplify libseccomp installation. Instead of using
temporary directories, let's install native libseccomp to a specified
directory, all the cross-builds to its subdirectories, and set
PKG_CONFIG_PATH and LD_LIBRARY_PATH in Dockerfile so that the built
library will found by pkg-config and the dynamic linker (without setting
LD_LIBRARY_PATH, ld picks up distro-provided libseccomp.so).
While at it, fix some bugs introduced by the abovementioned commit.
This fixes building runc in make targets like shell, dbuild,
integration, unittest -- i.e. those that depend on runcimage.
Fixes: f30244ee1b
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This fixes
> Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
Apparently, "the internets" disagree with the above, instead suggesting
using /usr/share/keyrings and a signed-by= declaration in sources.list.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The Debian_11 was not available in this repo at the time when commit 24d318b8b
was made, so we had to use Debian_10 URL for Debian 11 (apparently without any
consequences).
Now Debian_11 is available, so let's switch to it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This implements cross-build for "make release", moving the build into a
container. This way we can support arm, arm64, ppc, and whatnot.
* script/seccomp.sh: separate out of script/release.sh, amend to support
cross-compile and save needed environment variables to a file.
* Dockerfile: add installing libseccomp from source, as this is needed
for release builds.
* script/release.sh: amend to support more architectures in addition to
the native build. Additional arches can be added by specifying
"-a <arch>" argument (can be specified multiple times), or
"make RELEASE_ARGS="-a arm64" release" if called via make.
All supported architectures can be enabled via "make releaseall".
* Makefile: move "release" target to "localrelease", add "release" and
"releaseall" targets to build via the Dockerfile. This is done because
most distros (including Fedora and openSUSE) lack cross-glibc, which is
needed to cross-compile libseccomp.
* Makefile: remove 'cross' and 'localcross' targets, as this is now done
by the release script.
* .github/workflows/validate.yum: amend the release CI job to cross-build
for supported architectures, remove cross job.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Dockerfile: switch from go 1.15 to go 1.16.x.
Vagrantfile.centos7: switch from go 1.15 to go 1.16.4.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This simplifies and optimizes getting container images used for tests.
Currently, we have three different ways of getting images:
1. (for hello-world) the image is in this repo under tests/integration/testdata.
2. (for busybox) download it from github (the repo that is used for
preparing official Docker image) using curl.
3. (for debian) download from Docker hub, using skopeo and umoci.
To further complicate things, we have to do this downloading in multiple
scenarios (at least 4): locally, in github CI, from Dockefile, inside a
Vagrant VM. For each scenario, we have to install skopeo and umoci, and
those two are not yet universally available for all the distros that we
use.
Yet another complication is those images are used for tests/integration
(bats-driven tests) as well as for libcontainer/integration (go tests).
The tests in libcontainer/integration rely on busybox being available
from /busybox, and the bats tests just download the images to a
temporary location during every run.
It is also hard to support CI for other architectures, because all
the machinery for preparing images is so complicated.
This commit is an attempt to simplify and optimize getting images,
mostly by getting rid of skopeo and umoci dependencies, but also
by moving the download logic into one small shell script, which
is used from all the places.
Benefits:
- images (if not present) are only downloaded once;
- same images are used for both kind of tests (go and bats);
- same images are used for local and inside-docker tests
(because source directory is mounted into container);
- the download logic is located within 1 simple shell script.
[v2: fix eval; more doc to get-images; print URL if curl failed]
[v3: use "slim" debian, twice as small]
[v4: fix not using $image in setup_bundle]
[v5: don't remove TESTDATA from helpers.bash]
[v6: add i386 support]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
In here we have to use Docker, as Ubuntu does not support
all the architectures we're compile-testing here.
Since this is the only step that is using Docker,
there is no sense to separate `make runcimage` from
the rest of it. In case we'll have to use Docker image
more, it will make sense to do so.
While at it, ditch script/tmpmount (added by commit 1735ad788f),
because
- it required root (because mount);
- it is probably no longer needed.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This "reverts" commit 9ff7b82f9. We use the repo provided and maintained
by the CRIU team instead of compiling it from source.
While at it,
1. Don't install packages that were solely needed to compile CRIU.
2. Combine all apt-related stuff into a single step, so we don't
download and then remove apt metadata 3 times.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The current URL now gives 404. I looked in there and found that
apparently Debian_Unstable becomes Debian_10. Fix the URLs accordingly.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This patch adds a test based on real world usage of runc hooks
(libnvidia-container). We verify that mounting a library inside
a container and running ldconfig succeeds.
Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>
The bats testing framework we use for integration test is not maintained
since 2015 and was superceded by bats-core [1]. More to say, we were
using an unreleased version and relying on some features of it
(unfortunately I don't remember now what are those features exactly).
As Debian still packages very old version of bats from the old repo,
so let's Use recent bats-core from the new, supposedly better maintained,
github repo.
[1] https://github.com/sstephenson/bats/pull/269
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The Travis tests running on Fedora 31 with cgroup2 on Vagrant had the
CRIU parts disabled because of a couple of problems.
One problem was a bug in runc and CRIU handling that Andrei fixed.
In addition four patches from the upcoming CRIU 3.14 are needed for
minimal cgroup2 support (freezer and mounting of cgroup2). With Andrei's
fix and the CRIU cgroup2 support and the runc CRIU cgroup2 integration
it is now possible the checkpoint integration tests again on the Fedora
Vagrant cgroup2 based integration test.
To run CRIU based tests the modules of Fedora 31 (the test host system)
are mounted inside of the container used to test runc in the buster
based container with -v /lib/modules:/lib/modules.
Signed-off-by: Adrian Reber <areber@redhat.com>
Move adding the source code to the end, so that the busybox rootfs
doesn't have to be fetched again on each code change.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When github is giving HTTP 404 (or other error), it still sends some
document (to be viewed in a browser), but we have tar on the other end
of the pipe, so the end result is like this:
> Step 13/13 : RUN . tests/integration/multi-arch.bash && curl -o- -sSL `get_busybox` | tar xfJC - ${ROOTFS}
> 4872 ---> Running in ad84646a69f3
> 4873xz: (stdin): File format not recognized
> 4874tar: Child returned status 1
> 4875tar: Error is not recoverable: exiting now
> 4876The command '/bin/sh -c . tests/integration/multi-arch.bash && curl -o- -sSL `get_busybox` | tar xfJC - ${ROOTFS}' returned a non-zero code: 2
Add -f switch to curl, so it will display an HTTP error and exit:
> curl: (22) The requested URL returned error: 404 Not Found
> xz: (stdin): File format not recognized
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now
While at it, also
* remove -v from criu untar (too much output)
* remove -o - from curl (it does the same by default)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For the newly integrated feature to use CRIU configuration files the
test is broken without an additional CRIU patch.
The test changes CRIU's log file. Changing the log file is unfortunately
the only thing which is in broken in CRIU 3.11. But it is the easiest
option for testing. With CRIU 3.12 this will be fixed. All other CRIU
options can be changed with a CRIU configuration file.
With this change the CRIU 3.11 feature can be merged into runc with a
test and for the user it should just work, if they are not trying to
change CRIU's log file.
Signed-off-by: Adrian Reber <areber@redhat.com>
Upgrade CRIU to 3.11 in the Dockerfile as it includes the patch which
was manually added to fix an error with read-only root containers.
Now that the patch is part of the CRIU 3.11 release this simplifies the
Dockerfile (minimal).
Signed-off-by: Adrian Reber <areber@redhat.com>
For criu v3.10, a patch is needed for `@test "checkpoint --lazy-pages and restore"`.
Starting with v3.11, the patch will no longer be needed.
The issue had not been caught in Travis because the kernel is too old and the test
had not been executed in Travis.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
The current version of criu bundled in dockerfile failed to do checkpoint/restore test on my
system (v4.14.14). Upgrade to latest version v3.7 and also change the
repository name to point to the current official repo.
Signed-off-by: Daniel Dao <dqminh89@gmail.com>
Currently, integration test can't be done on arm64 platform due to several issues.
Fix points:
1, add busybox.tar with arm64 format
2, add hello-world.tar with arm64 format
Signed-off-by: Bin Lu <bin.lu@arm.com>
Currently, unit test can't be done on arm64 platform
due to multi-arch issue.
Fix points:
golang:1.8.0 doesn't support arm64.
We use golang:1.8 to replace it.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Enable several previously disabled tests (for the idmap execution mode)
for rootless containers, in addition to making all tests use the
additional mappings. At the moment there's no strong need to add any
additional tests purely for rootless_idmap.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Kir Kolyshkin