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>
(cherry picked from commit 5996fe143a)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.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>
(cherry picked from commit 936a59b07f)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
I no longer work at SUSE and thus this key (and email address) are no
longer associated with me.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
(cherry picked from commit a691486c83)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.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>
(cherry picked from commit f18e97d312)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
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>
(cherry picked from commit 3235c5a90a)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
When parsing mount options into recAttrSet and recAttrClr,
the code sets attr_clr to individual atime flags (e.g.
MOUNT_ATTR_NOATIME or MOUNT_ATTR_STRICTATIME) when clearing
atime attributes. However, this violates the kernel's
requirement documented in mount_setattr(2)[1]:
> Note that, since the access-time values are an enumeration
> rather than bit values, a caller wanting to transition to a
> different access-time setting cannot simply specify the
> access-time setting in attr_set, but must also include
> MOUNT_ATTR__ATIME in the attr_clr field. The kernel will
> verify that MOUNT_ATTR__ATIME isn't partially set in
> attr_clr (i.e., either all bits in the MOUNT_ATTR__ATIME
> bit field are either set or clear), and that attr_set
> doesn't have any access-time bits set if MOUNT_ATTR__ATIME
> isn't set in attr_clr.
Passing only a single atime flag (e.g. MOUNT_ATTR_RELATIME) in
attr_clr causes mount_setattr() to fail with EINVAL.
This change ensures that whenever an atime mode is updated,
attr_clr includes MOUNT_ATTR__ATIME to properly reset the
entire access-time attribute field before applying the new mode.
[1] https://man7.org/linux/man-pages/man2/mount_setattr.2.html
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit 5560d55bfd)
Signed-off-by: lifubang <lifubang@acmcoder.com>
Go 1.24 is no longer supported, and Go 1.25 (which we use in Dockerfile
for official binaries) is not being tested against.
So remove Go 1.24.x and add Go 1.25.x.
We keep Go 1.23.x is this is a minimally required version for this
branch.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Bump bats to the version from Fedora 42 (used in "fedora" job), so we
have the same version everywhere.
This also fixes an issue introduced by commit d31e6b87 (which forgot to
bump bats in GHA CI), and adds a note to the yaml in order to avoid the
same issue in the future.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 6af1d637ba)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since the recent CVE fixes, TestFdLeaksSystemd sometimes fails:
=== RUN TestFdLeaksSystemd
exec_test.go:1750: extra fd 9 -> /12224/task/13831/fd
exec_test.go:1753: found 1 extra fds after container.Run
--- FAIL: TestFdLeaksSystemd (0.10s)
It might have been caused by the change to the test code in commit
ff6fe13 ("utils: use safe procfs for /proc/self/fd loop code") -- we are
now opening a file descriptor during the logic to get a list of file
descriptors. If the file descriptor happens to be allocated to a
different number, you'll get an error.
Let's try to filter out the fd used to read a directory.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 5fbc3bb019)
Signed-off-by: lifubang <lifubang@acmcoder.com>
The dependency was initially slated for an upgrade from v0.6.0 to v0.6.1
to address an fd leak. However, due to compatibility constraints, we
instead downgrade to v0.5, using v0.5.2 which includes a backported fix
for the same issue.
Signed-off-by: lifubang <lifubang@acmcoder.com>
Since Go 1.23 is no longer supported, we should not use it.
Go 1.23 is still supported and is probably the best bet for
the release-1.2 branch.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This is to ensure that Go version in Dockerfile (which is used to build
release binaries) is:
- currently supported;
- used in CI tests.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit df4acc8867)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For some reason, some jobs in .github/workflows/validate.yml
have "fetch-depth: 0" argument to actions/checkout, meaning
"all history for all branches and tags". Obviously this is
not needed here.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit e0b00171eb0f338cf024760019abdd4e7dec690f)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 0200ccb53d9265c43f203fb98a9862407835eb23)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
On some systems (e.g., AlmaLinux 8), systemd automatically removes cgroup paths
when they become empty (i.e., contain no processes). To prevent this, we spawn
a dummy process to pin the cgroup in place.
Fix: https://github.com/opencontainers/runc/issues/5003
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit bba7647d09)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This will result in slower runs but we are having issues with
golangci-lint (false positives) that are most probably related
to caching.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 96dfa9de54)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This was always the intended behaviour but commit 72fbb34f50 ("rootfs:
switch to fd-based handling of mountpoint targets") regressed it when
adding a mechanism to create a file handle to the target if it didn't
already exist (causing the later stat to always succeed).
A lot of people depend on this functionality, so add some tests to make
sure we don't break it in the future.
Fixes: 72fbb34f50 ("rootfs: switch to fd-based handling of mountpoint targets")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
(cherry picked from commit 9a9719eeb4)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Kir Kolyshkin