There is no behavior change, it is just more readable to use -1 to mean
don't touch this.
Please note that if the GID is not mapped in the userns, by using -1 for
that no error is returned. We just avoid dealing with it completely, as
we want here.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
1. There is no need to have -p option in mkdir here, since
/home/rootless was already created by useradd above.
2. When there is no -p, there is no need to suppress the shellcheck
warning (which looked like this):
> In script/setup_host_fedora.sh line 21:
> mkdir -m 0700 -p /home/rootless/.ssh
> ^-- SC2174 (warning): When used with -p, -m only applies to the deepest directory.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Those are no longer needed with shellcheck v0.10.0 (possibly with an
earlier version, too, but I am too lazy to check that).
While at it, fix a typo in the comment.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This addresses a TODO item added by commit 40f146841
("keyring: handle ENOSYS with keyctl(KEYCTL_JOIN_SESSION_KEYRING)"),
as we do have runc init logging working fine for quite some time.
While at it, fix a typo in a comment (standart -> standard).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
It was a mistake to say that SELinux need to be in the enforcing mode
for these tests to run. It only needs to be enabled.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
In a nutshell:
- use git-core instead of git;
- do not install weak deps;
- do not install docs.
This results in less packages to install:
- 25 instead of 72 for almalinux-8
- 24 instead of 90 for almalinux-9
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This way, given a recent Go and Linux version, pidfd_send_signal will
be used under the hood.
Keep unix.Signal and unix.SignalName for logging (it is way more
readable than what os.Signal.String() provides).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Because we should switch to unix.PidFDSendSignal in new kernels, it has
been supported in go runtime. We don't need to add fall back to
unix.Kill code here.
Signed-off-by: lifubang <lifubang@acmcoder.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
- Unlike proprietary Vagrant, Lima remains to be an open source project
- GHA now natively supports nested virt on Linux runners
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
As per
- https://github.com/opencontainers/runtime-spec/pull/1253
- https://github.com/opencontainers/runtime-spec/pull/1261
CPU affinity can be set in two ways:
1. When creating/starting a container, in config.json's
Process.ExecCPUAffinity, which is when applied to all execs.
2. When running an exec, in process.json's CPUAffinity, which
applied to a given exec and overrides the value from (1).
Add some basic tests.
Note that older kernels (RHEL8, Ubuntu 20.04) change CPU affinity of a
process to that of a container's cgroup, as soon as it is moved to that
cgroup, while newer kernels (Ubuntu 24.04, Fedora 41) don't do that.
Because of the above,
- it's impossible to really test initial CPU affinity without adding
debug logging to libcontainer/nsenter;
- for older kernels, there can be a brief moment when exec's affinity
is different than either initial or final affinity being set;
- exec's final CPU affinity, if not specified, can be different
depending on the kernel, therefore we don't test it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is a big loop(at least 65 times) in `signal.Notify`, it costs as much
time as `runc init`, so we can call it in parallel ro reduce the container
start time. In a general test, it can be reduced about 38.70%.
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cyphar: move signal channel definition inside goroutine)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This removes libcontainer/cgroups packages and starts
using those from github.com/opencontainers/cgroups repo.
Mostly generated by:
git rm -f libcontainer/cgroups
find . -type f -name "*.go" -exec sed -i \
's|github.com/opencontainers/runc/libcontainer/cgroups|github.com/opencontainers/cgroups|g' \
{} +
go get github.com/opencontainers/cgroups@v0.0.1
make vendor
gofumpt -w .
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Prior to kernel Linux 5.5, F_SEAL_FUTURE_WRITE has a bug which maps
memory as shared between processes even if it is set as private. See
kernel commit 05d351102dbe ("mm, memfd: fix COW issue on MAP_PRIVATE and
F_SEAL_FUTURE_WRITE mappings") for more details.
According to the fcntl(2) man pages, F_SEAL_WRITE is enough:
> Furthermore, trying to create new shared, writable memory-mappings via
> mmap(2) will also fail with EPERM.
>
> Using the F_ADD_SEALS operation to set the F_SEAL_WRITE seal fails
> with EBUSY if any writable, shared mapping exists. Such mappings must
> be unmapped before you can add this seal.
F_SEAL_FUTURE_WRITE only makes sense if a read-write shared mapping in
one process should be read-only in another process. This is not case for
runc, especially not for the /proc/self/exe we are protecting.
Signed-off-by: Tomasz Duda <tomaszduda23@gmail.com>
(cyphar: improve the comment regarding F_SEAL_FUTURE_WRITE)
(cyphar: improve commit message)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>