Go 1.23 tightens access to internal symbols, and even puts runc into
"hall of shame" for using an internal symbol (recently added by commit
da68c8e3). So, while not impossible, it becomes harder to access those
internal symbols, and it is a bad idea in general.
Since Go 1.23 includes https://go.dev/cl/588076, we can clean the
internal rlimit cache by setting the RLIMIT_NOFILE for ourselves,
essentially disabling the rlimit cache.
Once Go 1.22 is no longer supported, we will remove the go:linkname hack.
(cherry picked from commit 584afc6756)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
It is past EOL and has been removed from GCE public images.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 40bb9c468e)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
CI should not fail and require attention every time a new codespell
version is released.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit b24fc9d2c4)
Signed-off-by: lifubang <lifubang@acmcoder.com>
./features.go:30: tru ==> through, true
...
./utils_linux.go:147: infront ==> in front
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 177c7d4f59)
Signed-off-by: lifubang <lifubang@acmcoder.com>
The issue is the same as in commit 1b2adcf but for RT scheduler;
the fix is also the same.
Test case by ls-ggg.
Co-authored-by: ls-ggg <335814617@qq.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit b60079e2e59670b8babd653002d8f469064fb244)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As reported in issue #4195, the new version(since 1.19) of go runtime
will cache rlimit-nofile. Before executing execve, the rlimit-nofile
of the process will be restored with the cache. In runc, this will
cause the rlimit-nofile set by the parent process for the container
to become invalid. It can be solved by clearing the cache.
Signed-off-by: ls-ggg <335814617@qq.com>
(cherry picked from commit f9f8abf310)
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit da68c8e37b)
Signed-off-by: lifubang <lifubang@acmcoder.com>
Since commit 551629417 we can (and should) use Info() to get access to
file stat. Do this.
While going over directory entries, a parallel runc delete can remove
an entry, and with the current code it results in a fatal error (which
was not observed in practice, but looks quite possible). To fix,
add a special case to continue on ErrNotExist.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 1a3ee4966c)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Instead of a huge if {} block, use continue.
Best reviewed with --ignore-all-space.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 095929b15e)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
this allows using a custom version string while building runc
without modifying the VERSION file
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
(cherry picked from commit 9d9273c926)
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
The motivation behind this change is to provide a flexible mechanism for
containers within a Kubernetes cluster to opt out of FIPS mode when necessary.
This change enables apps to simulate FIPS mode being enabled or disabled for testing
purposes. Users can control whether apps believe FIPS mode is on or off by manipulating
`/proc/sys/crypto/fips_enabled`.
Signed-off-by: Sohan Kunkerkar <sohank2602@gmail.com>
This adds support for syscalls up to Linux 6.7-rc3.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
(cherry picked from commit cdccf6d615)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Apparently, sometimes a short-lived "runc run" produces result with \r
and sometimes without. As a result, we have an occasional failure of
"runc run with tmpfs perms" test.
The solution (to the flaky test) is to use the first line of the output
(like many other tests do).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 6d27922005)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This is a security fix for CVE-2024-21626. See the advisory[1] for more
details.
Aleksa Sarai (6):
init: don't special-case logrus fds
libcontainer: mark all non-stdio fds O_CLOEXEC before spawning init
cgroup: plug leaks of /sys/fs/cgroup handle
init: close internal fds before execve
setns init: do explicit lookup of execve argument early
init: verify after chdir that cwd is inside the container
Hang Jiang (1):
Fix File to Close
[1]: https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv
Fixes: GHSA-xr7r-f8xq-vfvv CVE-2024-21626
LGTMs: cyphar AkihiroSuda kolyshkin lifubang
We close the logfd before execve so there's no need to special case it.
In addition, it turns out that (*os.File).Fd() doesn't handle the case
where the file was closed and so it seems suspect to use that kind of
check.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Given the core issue in GHSA-xr7r-f8xq-vfvv was that we were unknowingly
leaking file descriptors to "runc init", it seems prudent to make sure
we proactively prevent this in the future. The solution is to simply
mark all non-stdio file descriptors as O_CLOEXEC before we spawn "runc
init".
For libcontainer library users, this could result in unrelated files
being marked as O_CLOEXEC -- however (for the same reason we are doing
this for runc), for security reasons those files should've been marked
as O_CLOEXEC anyway.
Fixes: GHSA-xr7r-f8xq-vfvv CVE-2024-21626
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Kir Kolyshkin