It doesn't matter whether static or dynamic linking is used, runc
always needs libcontainer/nsenter, which is written in C and thus
requires cgo. Same is true for libcontainer/integration.
In addition, contrib/pkg/seccompagent also needs cgo (if seccomp build
tag is set), as it need to be linked against libseccomp C library.
By default, cgo is disabled when cross-compiling, meaning that
CGO_ENABLED=1 has to be set explicitly in such cases.
In all other cases (e.g. other contrib binaries) we do not need cgo.
Remove CGO_ENABLED=1 from GO_BUILD_STATIC (as it does not have anything
to do with static linking), and add it to all targets that require it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. Set to empty value by default.
2. Assume Linux (remove GOOS check, since we do not support other OSes).
3. Instead of using a "not-supported" list, use a "supported" list
(as Go release notes usually say which platforms are supported).
As of today, -buildmode=pie is supported for:
* linux/386, linux/amd64, linux/arm, linux/arm64, and linux/ppc64le
(since Go 1.6, see https://tip.golang.org/doc/go1.6#compiler)
* linux/s390x (since Go 1.7, which adds the initial port)
* linux/riscv64 (since Go 1.16, see
https://tip.golang.org/doc/go1.16#riscv)
NOTE this does not mean we support these architectures; it is merely
a way to see if -buildmode=pie can be used.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
LDFLAGS_COMMON are used from two places, so it makes sense to dedup.
LDFLAGS_STATIC is a preparation for the next commit.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
All we need is gcc, libc-dev, and binutils. In addition to that,
crossbuild-essential installs g++, libstdc++-dev, and a bunch of perl
packages and libraries which we do not need.
This should speed up image building, as well as make it smaller.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Dockerfile used to install libseccomp-dev packages for different
architectures. This is no longer true since commit f30244ee1b, which
changed to cross-compiling libseccomp (so we can get a static library
to link against).
Thus, adding extra architectures is no longer needed.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We do not use all the files from scripts, only seccomp.sh and lib.sh.
This prevents unneeded rebuild of the image if e.g.
scripts/release_build.sh has changed.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Do not set inheritable capabilities in runc spec, runc exec --cap,
and in libcontainer integration tests.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
With the updated git in Fedora 35, we can't build it via sudo:
ssh default 'sudo -i make -C /vagrant localunittest'
make: Entering directory '/vagrant'
fatal: unsafe repository ('/vagrant' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /vagrant
go build -trimpath "-buildmode=pie" -tags "seccomp" -ldflags "-X main.gitCommit= -X main.version=1.1.0+dev " -o runc .
error obtaining VCS status: exit status 128
Use -buildvcs=false to disable VCS stamping.
make: Leaving directory '/vagrant'
This commit should fix this.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Looking through git blame, this was added by commit 9fac18329
aka "Initial commit of runc binary", most probably by mistake.
Obviously, a container should not have access to tun/tap device, unless
it is explicitly specified in configuration.
Now, removing this might create a compatibility issue, but I see no
other choice.
Aside from the obvious misconfiguration, this should also fix the
annoying
> Apr 26 03:46:56 foo.bar systemd[1]: Couldn't stat device /dev/char/10:200: No such file or directory
messages from systemd on every container start, when runc uses systemd
cgroup driver, and the system runs an old (< v240) version of systemd
(the message was presumably eliminated by [1]).
[1] https://github.com/systemd/systemd/pull/10996/commits/d5aecba6e0b7c73657c4cf544ce57289115098e7
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is no need to parallelize lint and lint-extra jobs,
and they only differ with the arguments to golangci-lint.
Given that the longest time spent in these jobs is installing
libseccomp-dev, and that the second linter run can probably
benefit a lot from caching, it makes sense to merge them.
Move lint-extra from a separate job to a step in lint job.
The implementation is motivated by [1] and relies on the fact
that the last commit being fetched is the merge commit. So,
we need to set fetch-depth to 2 to be able to see the diff of
the merge commit -- and this is what golangci-lint is using.
[1] https://github.com/golangci/golangci-lint-action/issues/449#issuecomment-1096995821
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since the recent bump of actions/setup-go to v3 (commit
9d2268b9db), specifying "stable:" is no longer needed
when we want to try a beta or rc version of Go.
Remove it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The CAP_CHECKPOINT_RESTORE linux capability provides the ability to
update /proc/sys/kernel/ns_last_pid. However, because this file is under
/proc, and by default both K8s and CRI-O specify that /proc/sys should
be mounted as Read-Only, by default even with the capability specified,
a process will not be able to write to ns_last_pid.
To get around this, a pod author can specify a volume mount and a
hostpath to bind-mount /proc/sys/kernel/ns_last_pid. However, runc does
not allow specifying mounts under /proc.
This commit adds /proc/sys/kernel/ns_last_pid to the validProcMounts
string array to enable a pod author to mount ns_last_pid as read-write.
The default remains unchanged; unless explicitly requested as a volume
mount, ns_last_pid will remain read-only regardless of whether or not
CAP_CHECKPOINT_RESTORE is specified.
Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Now the only remaining file that needs shellcheck warnings to be fixed
is bash-completion. Note that in Makefile's TODO.
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>
One particularly bad one is ${codes[@]} which is fine in bash 4.4+,
but gives "codes[@]: unbound variable" with older bash versions,
such as with bash 4.2 used on CentOS 6. It's good that this is the only
array in the script that can potentially be empty.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
... and add this file to shellcheck target in Makefile.
These:
In script/check-config.sh line 27:
kernelMinor="${kernelVersion#$kernelMajor.}"
^----------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
kernelMinor="${kernelVersion#"$kernelMajor".}"
In script/check-config.sh line 103:
source /etc/os-release 2>/dev/null || /bin/true
^-------------^ SC1091 (info): Not following: /etc/os-release was not specified as input (see shellcheck -x).
In script/check-config.sh line 267:
NET_CLS_CGROUP $netprio
^------^ SC2206 (warning): Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Like this one:
In ./script/check-config.sh line 215:
if [ "$kernelMajor" -lt 5 ] || [ "$kernelMajor" -eq 5 -a "$kernelMinor" -le 1 ]; then
^-- SC2166 (warning): Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>