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>
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>
For some reason, ssh-keygen is unable to write to /root even as root on
AlmaLinux 8:
# id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0
# id -Z
ls -ld /root
# ssh-keygen -t ecdsa -N "" -f /root/rootless.key || cat /var/log/audit/audit.log
Saving key "/root/rootless.key" failed: Permission denied
The audit.log shows:
> type=AVC msg=audit(1744834995.352:546): avc: denied { dac_override } for pid=13471 comm="ssh-keygen" capability=1 scontext=system_u:system_r:ssh_keygen_t:s0 tcontext=system_u:system_r:ssh_keygen_t:s0 tclass=capability permissive=0
> type=SYSCALL msg=audit(1744834995.352:546): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5641c7587520 a2=241 a3=180 items=0 ppid=4978 pid=13471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=system_u:system_r:ssh_keygen_t:s0 key=(null)␝ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
A workaround is to use /root/.ssh directory instead of just /root.
While at it, let's unify rootless user and key setup into a single place.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We are seeing a ton on flakes on almalinux-8 CI job, all caused by criu
inability to freeze a cgroup. This was worked around in criu [1], but
obviously we can't rely on a distro vendor to update the package.
Let's use a copr (thanks to Adrian Reber!)
[1]: https://github.com/checkpoint-restore/criu/pull/2545
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>
- 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>
Also:
1. Change GO_VERSION to GO_VER_PREFIX, and move the "." from the jq
argument to the variable value. It allows to use something like
"1.25" to match "1.25rc" etc, but set to "1.24." for now to require
a released 1.24.x version.
2. Change PREFIX to URL_PREFIX.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
- drop Go 1.21;
- add Go 1.23;
- for a few jobs that were using Go 1.21, switch to 1.22;
Also, bump go to 1.22 in go.mod.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Remove CentOS 7 as it is EOL.
Add back RHEL 8 clone (CentOS Stream 8 was removed by commit
40bb9c468e).
Switch from CentOS Stream 9 to Almalinux 9.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
I tried to fix it, but it looks like older CentOS 7 kernel is the
ultimate reason why it doesn't work.
So, remove FIXME and add some explanation.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Now that runc-dmz is opt-in, we no longer need to try to detect whether
SELinux would cause issues for us. We can also remove the
special-purpose build-tag we added.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
It now comes with container-selinux 2:2.224.0-1.module_el8+712+4cd1bd69,
so we only need the kludge for CentOS 7 (which, I guess, is the sole
reason why we have this kludge at all).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Add a workaround for a problem of older container-selinux not allowing
runc to use dmz feature. If runc sees that SELinux is in enforced mode
and the container's SELinux label is set, it disables dmz.
Add a build tag, runc_dmz_selinux_nocompat, which disables the workaround.
Newer distros that ship container-selinux >= 2.224.0 (currently CentOS
Stream 8 and 9, RHEL 8 and 9, and Fedora 38+) may build runc with this
build tag set to benefit from dmz working with SELinux.
Document the build tag in the top-level and libct/dmz READMEs.
Use the build tag in our CI builds for CentOS Stream 9 and Fedora 38,
as they already has container-selinux 2.224.0 available in updates.
Add a TODO to use the build tag for CentOS Stream 8 once it has
container-selinux updated.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This is a test case to demonstrate the selinux vs dmz issue.
The issue is, runc calls selinux.SetExecLabel and then execs the
runc-dmz binary, but the execve is denied by selinux:
> type=PROCTITLE msg=audit(10/05/2023 22:54:07.911:10904) : proctitle=/tmp/bats-run-sGk2sn/runc.Ql243q/bundle/runc init
> type=SYSCALL msg=audit(10/05/2023 22:54:07.911:10904) : arch=x86_64 syscall=execveat success=no exit=EACCES(Permission denied) a0=0x6 a1=0xc0000b90fa a2=0xc0000a26a0 a3=0xc000024660 items=0 ppid=105316 pid=105327 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=8 comm=runc:[2:INIT] exe=/tmp/bats-run-sGk2sn/runc.Ql243q/bundle/runc subj=unconfined_u:unconfined_r:container_runtime_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(10/05/2023 22:54:07.911:10904) : avc: denied { entrypoint } for pid=105327 comm=runc:[2:INIT] path=/memfd:runc_cloned:runc-dmz (deleted) dev="tmpfs" ino=2341 scontext=system_u:system_r:container_t:s0:c4,c5 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=file permissive=0
Once that error is fixed (by adding a selinux rule that enables it), we
see one more error, also related to executing a file on tmpfs.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We were not running localrootlessintegration test on CentOS Stream 9
because of some failures fixed by previous commits.
Enable rootless integration with both systemd and fs drivers.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As of today, vagrant stopped working, my best guess is due to bad
caching. Here's an excerpt from logs:
...
vagrant plugin install vagrant-libvirt
Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
Building native extensions. This could take a while...
Installed the plugin 'vagrant-libvirt (0.12.1)'!
...
uname -s ; cat Vagrantfile.$DISTRO
Linux
...
Downloaded 481Mb in 4.096201s.
Cache hit for vagrant-8be35383dc00f23d080ff00b2a724c938d650254861f26b67624c28e3fe5e6ae!
...
Vagrant failed to initialize at a very early stage:
The plugins failed to initialize correctly. This may be due to manual
modifications made within the Vagrant home directory.
...
Error message given during initialization: Unable to resolve dependency:
user requested 'vagrant-libvirt (= 0.12.0)'
...
The problem is, vagrant cache overwrites newer plugin with an older one.
Let's only cache the downloaded image.
Also, change the cache fingerprint script (remove "Linux").
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
A version of vagrant available from the stock repos (2.2.19) is too old
and contains a bug that prevents downloading Fedora 38 image (see [1]).
Use packages from hashicorp repo, which currently has vagrant 2.3.4.
This resolves the problem of downloading the latest Fedora image.
Also, vagrant-libvirt plugin from Ubuntu repos is not working with
vagrant from hashicorp, so switch to using "vagrant plugin install".
The downside it, this takes extra 4 minutes or so in our CI, and I
am not sure how to cache it or speed it up.
[1] https://github.com/opencontainers/runc/pull/3835#issuecomment-1519321619
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. Do not use echo, as this results in lines like this:
...
echo "-----"
-----
...
2. Move "cat /proc/cpuinfo" to be the last one, as the output is usually
very long.
3. Add "go version" to CentOS jobs.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This variable is used in curl to download a go release, so we are using
the initial Go 1.19 release in Cirrus CI, not the latest Go 1.19.x
release.
From the CI perspective, it makes more sense to use the latest release.
Add some jq magic to extract the latest minor release information
from the download page, and use it.
This brings Cirrus CI jobs logic in line with all the others (GHA,
Dockerfile), where by 1.20 we actually mean "latest 1.20.x".
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This version is already used by Cirrus CI Fedora 37 job, but other CI
jobs are still using 1.3.0.
Bump it everywhere so we can enjoy new version features and fixes.
For one thing, I noticed that new bats is reporting error location
correctly.
We will also be able to use "run !" and "run -N" commands.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
It used to be enabled by default, but not as of last few weeks.
While at it, add rpm -q command to make sure all required RPMS were in
fact installed (at least CentOS 7 yum exits with 0 when some packages
requested are not available).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This is done to make sure the script is working correctly in different
environments (distro and kernel versions). In addition, we can see in
test logs which kernel features are enabled.
Note that I didn't want to have a separate job for GHA CI, so I just
added this to the end of shellcheck one.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Require go 1.17 from now on, since go 1.16 is no longer supported.
Drop go1.16 compatibility.
NOTE we also have to install go 1.18 from Vagrantfile, because
Fedora 35 comes with Go 1.16.x which can't be used.
Note the changes to go.mod and vendor are due to
https://go.dev/doc/go1.17#tools
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As reported in [1], in a case where read-only fuse (sshfs) mount
is used as a volume without specifying ro flag, the kernel fails
to remount it (when adding various flags such as nosuid and nodev),
returning EPERM.
Here's the relevant strace line:
> [pid 333966] mount("/tmp/bats-run-PRVfWc/runc.RbNv8g/bundle/mnt", "/proc/self/fd/7", 0xc0001e9164, MS_NOSUID|MS_NODEV|MS_REMOUNT|MS_BIND|MS_REC, NULL) = -1 EPERM (Operation not permitted)
I was not able to reproduce it with other read-only mounts as the source
(tried tmpfs, read-only bind mount, and an ext2 mount), so somehow this
might be specific to fuse.
The fix is to check whether the source has RDONLY flag, and retry the
remount with this flag added.
A test case (which was kind of hard to write) is added, and it fails
without the fix. Note that rootless user need to be able to ssh to
rootless@localhost in order to sshfs to work -- amend setup scripts
to make it work, and skip the test if the setup is not working.
[1] https://github.com/containers/podman/issues/12205
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Also rename `Vagrantfile.fedora%d` to `Vagrantfile.fedora` so that
we do not need to reset the commit log on upgrading the Fedora release.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
GCP images description at [1] claims that:
- For CentOS 8 and CentOS Stream 8, the PowerTools repository is
enabled.
- For CentOS 7, EPEL is enabled.
Apparently,
- we do not need epel for centos-stream-8;
- powertools is not enabled on centos-stream-8 despite [1].
Anyway, the less yum commands the better, as we have seen those fail
sometimes due to occasional networking problems etc.
[1] https://cloud.google.com/compute/docs/images/os-details#centos
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As Cirrus CI does not provide a real terminal this uses the same
'ssh -tt' workaround as the Vagrant setup. This sets up the
CentOS 7 and 8 to allow SSH as root to localhost so that we can run
all the tests via 'ssh -tt'.
Not going through vagrant reduces CI times for CentOS 7 and 8 from 6
minutes to 4 minutes.
Signed-off-by: Adrian Reber <areber@redhat.com>
Kir Kolyshkin