The intention of commit 531e29e192 ("script/lib.sh: set GOARM=5 for
armel, GOARM=6 for armhf") was to properly support older ARM platforms
with our release builds.
However, we have never been able to support ARMv6 for our builds because
we use the Debian compiler to build the libseccomp we statically compile
into our binaries and (as per the now-deleted comment itself) Debian
treats armhf as being ARMv7 so the final binaries we produced were
always only ever compatible with ARMv7+.
This was a bit of an oddity before but when building libpathrs for
releases we will need to use Rust which makes the target more explicit
(and while it does support armhf, we are using the Debian-packaged Rust
cross-compiler and thus are in the same dilemma with what Debian
considers "armhf" to be).
All-in-all, it's better to just bite the bullet and just follow Debian
here properly.
Fixes: 531e29e192 ("script/lib.sh: set GOARM=5 for armel, GOARM=6 for armhf")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Debian 13 (trixie) was released a few months ago and it's probably
prudent to just upgrade. This is also necessary to get access to riscv64
repositories when we build libpathrs for inclusion in our runc binaries.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
When deprecating Relabel field, its json attributes were mistakenly
removed, so now it is:
- saved to JSON under "Relabel" (rather than "relabel");
- won't be ignored if empty.
Let's fix it before it's too late.
Fixes: 8b2b5e94 ("libct: remove relabeling dead code")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
It makes more sense to save whether we should cleanup the directory
after it gets created (to avoid error cases deleting a different
directory) as well as tying this check to the existing os.ErrExist
check rather than doing an extra stat(2).
Fixes: e2baa3ad10 ("Intel RDT: update according to spec changes.")
Suggested-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This fixes random failures to start a container in conmon integration
tests (see issue 5151).
I guess we need to find another way to fix issue 4645.
This reverts commit 1b39997e73.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is no way to set Mount.Relabel field via OCI spec (config.json),
and so the relabeling code is never used.
My guess it's a leftover from times when runc used to be part of Docker.
Remove it, and mark Relabel field as deprecated.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is one proposed clarification to the OCI spec: the subdirectory
needs to be deleted. Runc already does that, but the clarification adds
for directory removal only if the directory was created by us.
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
unix.CPUSet is limited to 1024 CPUs. Calling
unix.SchedSetaffinity(pid, cpuset) removes all CPUs starting from 1024
from allowed CPUs of pid, even if cpuset is all ones. As a
consequence, when runc tries to reset CPU affinity to "allow all" by
default, it prevents all containers from CPUs 1024 onwards.
This change uses a huge CPU mask to play safe and get all possible
CPUs enabled with a single sched_setaffinity call.
Fixes: #5023
Signed-off-by: Antti Kervinen <antti.kervinen@intel.com>
Some maintainers appear to have removed their PGP keys, which causes
"gpg --import" during "make validate-keyring" to fail. The solution is
to switch to a non-fatal warning if no keys were imported.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This was a really ugly hack to try to reduce the impact of our original
set of CVE-2019-5736 mitigations, but unfortunately had too many caveats
to its use to ever be really useful. In addition, it was completely
obsoleted by the migration to using an detached overlayfs mount in
commit 515f09f7b1 ("dmz: use overlayfs to write-protect /proc/self/exe
if possible").
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These were all marked deprecated in commit a75076b4a4 ("Switch to
opencontainers/cgroups") when we switched maintenance of our cgroup code
to opencontainers/cgroups.
Users have had ample time to switch to opencontainers/cgroups
themselves, so we can finally remove this.
Note that the whole libcontainer/devices package will be moved to
moby/sys in the near future, so this whole package will be marked
deprecated soon.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These were inadvertently added to our exported APIs by commit
eeda7bdf80cca ("Add memory policy support"). We couldn't remove them
from runc 1.4.x, but we deprecated them in commit 3741f9186d
("libct/configs: mark MPOL_* constants as deprecated") and marked them
for removal in runc 1.5. Users should never have used these in the first
place.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This was deprecated in commit e6a4870e4ac40 ("libct: better errors for
hooks"), and users have had ample time to migrate to Hooks.Run since.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These were all marked deprecated in commit a75076b4a4 ("Switch to
opencontainers/cgroups") when we switched maintenance of our cgroup code
to opencontainers/cgroups.
Users have had ample time to switch to opencontainers/cgroups
themselves, so we can finally remove this.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
There is a chance of panic here -- eliminate it.
Add a test case (which panics before the fix).
Reported-by: Luke Hinds <luke@stacklok.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Example code in README is outdated (especially since cgroups is moved to
a separate repository) and lacks proper import statements. And, since it
is not code, it is hard to keep it up to date.
Let's move it out to the example_test.go file and refer to it. Note we
still don't run it, but it will be compiled and linted in CI.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Fix *some* of the prealloc linter warnings. While it does not make sense
to address all warnings (or add prealloc to the list of linters we run
in CI), some do make sense.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
SCMP_ACT_KILL terminates the process with a fatal signal, which may
produce a core dump depending on the host configuration.
While this is harmless on ephemeral CI instances, it can leave unwanted
core files on developer or customer systems. It also interferes with
test environments that detect unexpected core dumps.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
When container-selinux 4:2.246.0-1.el10 is installed, it produces the
following %post script warnings:
> ...
> Running scriptlet: container-selinux-4:2.246.0-1.el10.noarch 26/37
> Installing : container-selinux-4:2.246.0-1.el10.noarch 26/37
> Running scriptlet: container-selinux-4:2.246.0-1.el10.noarch 26/37
> libsemanage.semanage_pipe_data: Child process /usr/libexec/selinux/hll/pp failed with code: 255. (No data available).
> libsemanage.semanage_compile_module: container: libsepol.policydb_read: policydb module version 24 does not match my version range 4-23.
> libsemanage.semanage_compile_module: container: libsepol.sepol_module_package_read: invalid module in module package (at section 0).
> libsemanage.semanage_compile_module: container: libsepol.sepol_ppfile_to_module_package: Failed to read policy package.
> libsemanage.semanage_direct_commit: Failed to compile hll files into cil files. (No data available).
> semodule: Failed!
> ...
For some reason, dnf install still succeeds, but when the selinux tests
fail with:
> chcon: failed to change context of '/tmp/bats-run-3MMyYP/runc.szTqBc/bundle/runc' to ‘system_u:object_r:container_runtime_exec_t:s0’: Invalid argument
All this is fixed once policycoreutils is added to the list of RPMS so
it is updated (from 3.9-3.el10 to 3.10-1.el10) during the same
transaction.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Commit 67f6c37b ("ci/gha: switch to ubuntu 24.04") switched most GHA CI
to Ubuntu 24.04 except for one job. It says:
> Leave ubuntu-22.04 for ci/cross-i386 (issue with systemctl restart hang
> after apt install). This can be addressed separately later.
Assuming the issue it already fixed (updated systemd or something),
let's finalize the 24.04 switch.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Previously, when prepareCgroupFD would not open container's cgroup
(as configured in config.json and saved to state.json), it returned
a fatal error, as we presumed a container can't exist without its own
cgroup.
Apparently, it can. In a case when container is configured without
cgroupns (i.e. it uses hosts cgroups), and /sys/fs/cgroup is mounted
read-write, a rootful container's init can move itself to an entirely
different cgroup (even a new one that it just created), and then the
original container cgroup is removed by the kernel (or systemd?) as
it has no processes left. By the way, from the systemd point of view
the container is gone. And yet it is still there, and users want
runc exec to work!
And it worked, thanks to the "let's try container init's cgroup"
fallback as added by commit c91fe9aeba ("cgroup2: exec: join the
cgroup of the init process on EBUSY"). The fallback was added for
the entirely different reason, but it happened to work in this very
case, too.
This behavior was broken with the introduction of CLONE_INTO_CGROUP
support.
While it is debatable whether this is a valid scenario when a container
moves itself into a different cgroup, this very setup is used by e.g.
buildkitd running in a privileged kubernetes container (see issue 5089).
To restore the way things are expected to work, add the same "try
container init's cgroup" fallback into prepareCgroupFD.
While at it, simplify the code flow.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. Refactor addIntoCgroupV2 in an attempt to simplify it.
2. Fix the bug of not trying the init cgroup fallback if
rootlessCgroup is set. This is a bug because rootlessCgroup
tells to ignore cgroup join errors, not to never try the fallback.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Aleksa Sarai