Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

Kir Kolyshkin (3):
  VERSION: back to development
  VERSION: release 1.1.3
  ci: add basic checks for CHANGELOG.md

LGTMs: thaJeztah cyphar
Closes #3490

Due to a bug in commit 9c44407, when the user and mount namespaces
are used, and the bind mount is followed by the cgroup mount in the
spec, the cgroup is mounted using the bind mount's mount fd.

This can be reproduced with podman 4.1 (when configured to use runc):

$ podman run --uidmap 0:100:10000 quay.io/libpod/testimage:20210610 mount
Error: /home/kir/git/runc/runc: runc create failed: unable to start container process: error during container init: error mounting "cgroup" to rootfs at "/sys/fs/cgroup": mount /proc/self/fd/11:/sys/fs/cgroup/systemd (via /proc/self/fd/12), flags: 0x20502f: operation not permitted: OCI permission denied

or manually with the spec mounts containing something like this:

    {
      "destination": "/etc/resolv.conf",
      "type": "bind",
      "source": "/userdata/resolv.conf",
      "options": [
        "bind"
      ]
    },
    {
      "destination": "/sys/fs/cgroup",
      "type": "cgroup",
      "source": "cgroup",
      "options": [
        "rprivate",
        "nosuid",
        "noexec",
        "nodev",
        "relatime",
        "ro"
      ]
    }

The issue was not found earlier since it requires using userns, and even then
mount fd is ignored by mountToRootfs, except for bind mounts, and all the bind
mounts have mountfd set, except for the case of cgroup v1's /sys/fs/cgroup
which is internally transformed into a bunch of bind mounts.

This is a minimal fix for the issue, suitable for backporting.

A test case is added which reproduces the issue without the fix applied.

Fixes: 9c44407 ("Open bind mount sources from the host userns")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit d370e3c)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

Kir Kolyshkin (1):
  libct: fix mounting via wrong proc fd

LGTMs: AkihiroSuda cyphar
Closes #3511

The following failure was observed in CI (on centos-stream-8 in
integration-cgroup suite):

	not ok 42 runc delete
	 (from function `fail' in file tests/integration/helpers.bash, line 338,
	  in test file tests/integration/delete.bats, line 30)
	   `[ "$output" = "" ] || fail "cgroup not cleaned up correctly: $output"' failed
	....
	cgroup not cleaned up correctly: /sys/fs/cgroup/pids/system.slice/tmp-bats\x2drun\x2d68012-runc.IPOypI-state-testbusyboxdelete-runc.zriC8C.mount
	/sys/fs/cgroup/cpu,cpuacct/system.slice/tmp-bats\x2drun\x2d68012-runc.IPOypI-state-testbusyboxdelete-runc.zriC8C.mount
	...

Apparently, this is a cgroup systemd creates for a mount unit which
appears then runc does internal /proc/self/exe bind-mount. The test
case should not take it into account.

The second problem with this test is it does not check that cgroup
actually exists when the container is running (so checking that it
was removed after makes less sense). For example, in rootless mode
the cgroup might not have been created.

Fix the find arguments to look for a specific cgroup name, and add
a check that these arguments are correct (i.e. the cgroup is found
when the container is running).

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 728571c)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

A couple of test cases in delete.bats check that a particular cgroup
exists (or doesn't exist) using find. This is now resulting in errors
like these:

        find: ‘/sys/fs/cgroup/blkio/azsec’: Permission denied
        find: ‘/sys/fs/cgroup/blkio/azsec_clamav’: Permission denied
        find: ‘/sys/fs/cgroup/cpu,cpuacct/azsec’: Permission denied
        find: ‘/sys/fs/cgroup/cpu,cpuacct/azsec_clamav’: Permission denied
        find: ‘/sys/fs/cgroup/memory/azsec’: Permission denied
        find: ‘/sys/fs/cgroup/memory/azsec_clamav’: Permission denied

leading to test case failures.

Apparently, GHA runs something else on a test box, so we get this.

To fix, ignore non-zero exit code from find, and redirect its stderr
to /dev/null.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

This is a partial backport of commit 6e1d476 from main branch.

Instead of specifying path to criu binary, use whatever is found in
$PATH.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

Older criu builds fail to work properly on CentOS Stream 9 due to
changes in glibc's rseq.

Skip criu tests if an older criu version is found.

Fixes: #3532

Cherry picked from commit 4fd4af5.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

Kir Kolyshkin (4):
  CI: workaround CentOS Stream 9 criu issue
  tests/int: don't use --criu
  [1.1] ci: fix delete.bats for GHA
  tests/int: runc delete: fix flake, enable for rootless

LGTMs: AkihiroSuda cyphar
Closes #3538

Signed-off-by: guodong <guodong9211@gmail.com>

guodong (1):
  [1.1] libct/nsenter: switch to sane_kill()

LGTMs: AkihiroSuda cyphar
Closes #3536

When starting a new container, and the very last step of executing of a
user process fails (last lines of (*linuxStandardInit).Init), it is too
late to print a proper error since both the log pipe and the init pipe
are closed.

This is partially mitigated by using exec.LookPath() which is supposed
to say whether we will be able to execute or not. Alas, it fails to do
so when the binary to be executed resides on a filesystem mounted with
noexec flag.

A workaround would be to use access(2) with X_OK flag. Alas, it is not
working when runc itself is a setuid (or setgid) binary. In this case,
faccessat2(2) with AT_EACCESS can be used, but it is only available
since Linux v5.8.

So, use faccessat2(2) with AT_EACCESS if available. If not, fall back to
access(2) for non-setuid runc, and do nothing for setuid runc (as there
is nothing we can do). Note that this check if in addition to whatever
exec.LookPath does.

Fixes #3520

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 957d97b)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

[1.1] Fix error from runc run on noexec fs

When golang 1.19 is used to build unit tests on 386, it fails like this:

 sudo -E PATH="$PATH" -- make GOARCH=386 CGO_ENABLED=1 localunittest
 <...>
 go test -timeout 3m -tags "seccomp"  -v ./...
 <...>
 # github.com/opencontainers/runc/libcontainer/capabilities.test
 runtime/cgo(.text): unknown symbol __stack_chk_fail_local in pcrel
 runtime/cgo(.text): unknown symbol __stack_chk_fail_local in pcrel
 runtime/cgo(.text): unknown symbol __stack_chk_fail_local in pcrel
 runtime/cgo(.text): unknown symbol __stack_chk_fail_local in pcrel
 runtime/cgo(.text): unknown symbol __stack_chk_fail_local in pcrel
 runtime/cgo(.text): relocation target __stack_chk_fail_local not defined
 runtime/cgo(.text): relocation target __stack_chk_fail_local not defined

The fix is to add CGO_CFLAGS=-fno-stack-protector.

See also:
 - docker-library/golang#426
 - https://go.dev/issue/52919
 - https://go.dev/issue/54313
 - https://go-review.googlesource.com/c/go/+/421935

Cherry picked from commit 589a9d5.

Conflict in .github/workflows/test.yml due to missing commit dafcacb.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

[1.1] ci/gha: fix cross-386 job vs go 1.19

Recently released codespell 2.2 adds some more false positives,
such as:

	./Makefile:78: ro ==> to, row, rob, rod, roe, rot
	./Makefile:88: ro ==> to, row, rob, rod, roe, rot
	./notify_socket.go:51: ro ==> to, row, rob, rod, roe, rot
	./LICENSE:128: complies ==> compiles
	./go.sum:59: BU ==> BY
	./types/features/features.go:17: ro ==> to, row, rob, rod, roe, rot
	./libcontainer/rootfs_linux.go:52: ro ==> to, row, rob, rod, roe, rot
	./libcontainer/rootfs_linux.go:166: ro ==> to, row, rob, rod, roe, rot
	....
	./tests/integration/cgroup_delegation.bats:38: inh ==> in
	...

To fix:
 - exclude go.sum;
 - add ro and complies to the list of ignored words;
 - s/inh/inherit in cgroup_delegation.bats.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit df9e32b)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

[1.1] ci: fix for codespell 2.2

A regression reported for runc v1.1.3 says that "runc exec -t" fails
after doing "systemctl daemon-reload":

> exec failed: unable to start container process: open /dev/pts/0: operation not permitted: unknown

Apparently, with commit 7219387 we are no longer adding
"DeviceAllow=char-pts rwm" rule (because os.Stat("char-pts") returns
ENOENT).

The bug can only be seen after "systemctl daemon-reload" because runc
also applies the same rules manually (by writing to devices.allow for
cgroup v1), and apparently reloading systemd leads to re-applying the
rules that systemd has (thus removing the char-pts access).

The fix is to do os.Stat only for "/dev" paths.

Also, emit a warning that the path was skipped. Since the original idea
was to emit less warnings, demote the level to debug.

Note this also fixes the issue of not adding "m" permission for block-*
and char-* devices.

A test case is added, which reliably fails before the fix
on both cgroup v1 and v2.

This is a backport of commit 58b1374
to release-1.1 branch.

Fixes: #3551
Fixes: 7219387
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

[1.1] Fix failed exec after systemctl daemon-reload (regression in 1.1.3)

Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>