Since switching to Go 1.25 in go.mod, the "detect fd leaks" test fails
like this:
> not ok 57 runc create[detect fd leak as comprehensively as possible]
> # (in test file tests/integration/create.bats, line 76)
> # `[ "$violation_found" -eq 0 ]' failed
> ...
> # Violation: FD 9 -> '/system.slice/runc-test_busybox.scope/cpu.cfs_quota_us'
> # Violation: FD 10 -> '/system.slice/runc-test_busybox.scope/cpu.cfs_period_us'
> ...
This happens because Go 1.25 adds a feature to dynamically set GOMAXPROC
based on current CPU quota values. This feature can be disabled by setting
GODEBUG=containermaxprocs=0,updatemaxprocs=0
but it is harmless to keep it (except for the above test failure).
Add an exception to the test case.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This uses preopened rootfs in Chdir and pivotRoot.
While at it, add O_PATH when opening oldroot in pivotRoot.
Co-authored-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: lfbzhm <lifubang@acmcoder.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
A lot of filesystem-related stuff happens inside the container root
directory, and we have used its name before. It makes sense to pre-open
it and use a *os.File handle instead.
Function names in internal/pathrs are kept as is for simplicity (and it
is an internal package), but they now accept root as *os.File.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Indeed, it does not make sense to prepend c.root once we started using
MkdirAllInRoot in commit 63c29081.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Li Fubang (3):
test: check mount source fds are cleaned up with idmapped mounts
libct: close mount source fd as soon as possible
libct: add a nil check for mountError
LGTMs: kolyshkin rata cyphar
word boundary anchor \> is present only in GNU awk implementation. This
will not work if we are building libpathrs inside a container like
debian/ubuntu which uses mawk. Therefore switch to a POSIX compatible
regex that can be used with all implementations of awk to find the
system libc path
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
This commit factors out setupAndMountToRootfs without changing any
logic. Use "Hide whitespace changes" during review to focus on the
actual changes.
The refactor ensures the mount source file descriptor is closed via
defer in each loop iteration, reducing the total number of open FDs
in runc. This helps avoid hitting the file descriptor limit under
high concurrency or when handling many mounts.
Signed-off-by: lifubang <lifubang@acmcoder.com>
A bit of history. EXTRA_BUILDTAGS was introduced in commit dac417174,
as a quick way to add some extra Go build tags to the runc build.
Later, commit 767bc008 changed Makefile to not get EXTRA_TAGS from the
shell environment, as the name is quite generic and some unrelated
environment variable with that name can affect runc build. While such
change does make sense, it makes it more complicated to pass build tags
in CI and otherwise (see e.g. commit 0e1fe368a).
Moreover, runc build uses some Go build tags by default (via Makefile),
and while it is easy to add more build tags (via EXTRA_BUILDTAGS), in
order to remove some existing tags one has to redefine BUILDTAGS from
scratch, which is not very convenient (again, see commit 0e1fe368a which
gets the current value of BUILDTAGS from the Makefile in order to remove
a single tag).
To handle all of the above, let's do this:
- implement RUNC_BUILDTAGS, fixing the issue of not-so-unique name;
- allow to get RUNC_BUILDTAGS from shell environment;
- implement a feature to remove a build tag from default set by
prefixing it with "-" (as in RUNC_BUILDTAGS="-seccomp");
- document all this in README;
- make CI use the new feature;
- keep EXTRA_BUILDTAGS for backward compatibility, add a make warning
and a TODO to remove it for runc 1.6.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This adds support for WaitKillableRecv seccomp flag
(also known as SCMP_FLTATR_CTL_WAITKILL in libseccomp and
as SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV in the kernel).
This requires:
- libseccomp >= 2.6.0
- libseccomp-golang >= 0.11.0
- linux kernel >= 5.19
Note that this flag does not make sense without NEW_LISTENER, and
the kernel returns EINVAL when SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV
is set but SECCOMP_FILTER_FLAG_NEW_LISTENER is not set.
For runc this means that .linux.seccomp.listenerPath should also be set,
and some of the seccomp rules should have SCMP_ACT_NOTIFY action. This
is why the flag is tested separately in seccomp-notify.bats.
At the moment the only adequate CI environment for this functionality is
Fedora 43. On all other platforms (including CentOS 10 and Ubuntu 24.04)
it is skipped similar to this:
> ok 251 runc run [seccomp] (SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV) # skip requires libseccomp >= 2.6.0 and API level >= 7 (current version: 2.5.6, API level: 6)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Found out that these changes were backported to release-1.4 (PR 5040)
and made its way into runc v1.4.0, but were missing from its CHANGELOG.
Move the item to v1.4.0 changelog, and add a backport PR reference.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Aleksa Sarai (4):
VERSION: back to development
VERSION: release v1.5.0-rc.1
CHANGELOG: forward-port v1.4.1 entry
CHANGELOG: add original PR references to backports
LGTMs: rata lifubang
Some of the patches in the "unreleased" section were backported and so
they can be moved to the v1.4.1 section to some unneeded avoid
duplication.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
When going through the changelog for v1.5.0-rc.1, these PRs were merged
but not referenced by their original PR number in the changelog, making
it harder to figure out which patches since v1.4.0-rc.1 are in
v1.5.0-rc.1 or v1.4.0.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Commit 192e3d416f ("ci: add conmon tests run") was merged without
rebasing on top of commit e2c989b7e1 ("build: enable libpathrs by
default"), causing build failures when it was merged.
The solution is to just use the same install script as the rest of CI
from commit 7322b05f41 ("ci: build and install libpathrs").
Fixes: 192e3d416f ("ci: add conmon tests run")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Aleksa Sarai (11):
gha: test both with and without libpathrs
build: enable libpathrs by default
ci: build and install libpathrs
build: enable builds with libpathrs
deps: update to cyphar.com/go-pathrs@v0.2.4
README: document libpathrs build tag
script: seccomp.sh -> build-seccomp.sh
build: rename /opt/libseccomp cdylib directory
build: treat armhf as ARMv7
dockerfile: switch to Debian 13
integration: output debug information in fd leak test
LGTMs: rata kolyshkin AkihiroSuda
This entry was added by commit 653161f6d8 ("docs/spec-conformance.md:
update for spec v1.3.0") but the spec was updated before the v1.3.0
release to remove this requirement for poststart hooks in order to match
runc's current behaviour.
Fixes: 653161f6d8 ("docs/spec-conformance.md: update for spec v1.3.0")
Ref: opencontainers/runtime-spec#1262
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
We do plan to make libpathrs required in the future, but in the meantime
we should test both with and without libpathrs in our CI to catch
regressions for users that will not use libpathrs initially.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
libpathrs has better hardening against certain attacks (most notably on
older kernels) so we should use it by default. This opens the door to
us using cyphar.com/go-pathrs in the future in order to remove some of
our internal/pathrs wrappers (that reimplement bits of libpathrs).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
pathrs-lite supports transparently switching to libpathrs.so as the
backend with the "libpathrs" build tag. In order to make this work
properly with our CI and release build scripts, we we need to have a
similar setup as with we do with libseccomp.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Ever since v0.6.0 of github.com/cyphar/filepath-securejoin, pathrs-lite
has been able to transparently switch to using libpathrs as the backend
for safe path resolution (at compile-time, using a build tag). Note that
because build-tags apply globally, this allows for us to easily opt
pure-Go dependencies into all using libpathrs as well for our binaries.
In a future patch this will likely be enabled by default, but document
that this is an option for downstreams that want to opt-in to using
libpathrs.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
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>
dependabot[bot]