Tested on a REHL box and found out that the mounts were not showing up
Had a logic flaw, where if the mount was "host:container"
Was setting the mount source to "host" and destination to "ctrRunDir/container"
When instead, the mount source should be "ctrRunDir/container" and destination "container"
with the data copied from "host" to "ctrRunDir/container"
Signed-off-by: umohnani8 <umohnani@redhat.com>
We now can pass 37/55 tests with this PR. Remaining tests include may be fixed
with 1.8.
[Fail] [k8s.io] Security Context bucket [It] runtime should support RunAsUserName
[Fail] [k8s.io] Security Context NamespaceOption [It] runtime should support HostPID
[Fail] [k8s.io] PodSandbox runtime should support sysctls [It] should support unsafe sysctls
[Fail] [k8s.io] PodSandbox runtime should support basic operations on PodSandbox [It] runtime should support removing PodSandbox [Conformance]
[Fail] [k8s.io] Streaming runtime should support streaming interfaces [It] runtime should support portforward [Conformance]
[Fail] [k8s.io] Security Context SeccompProfilePath [It] runtime should not support a custom seccomp profile without using localhost/ as a prefix
[Fail] [k8s.io] Image Manager [It] listImage should get exactly 2 repoTags in the result image [Conformance]
[Fail] [k8s.io] PodSandbox runtime should support sysctls [It] should support safe sysctls
[Fail] [k8s.io] Security Context NoNewPrivs [It] should not allow privilege escalation when true
[Fail] [k8s.io] Security Context SeccompProfilePath [It] runtime should support an seccomp profile that blocks setting hostname with SYS_ADMIN
[Fail] [k8s.io] Container runtime should support mount propagation [It] mount with 'rslave' should support propagation from host to container
[Fail] [k8s.io] Container runtime should support mount propagation [It] mount with 'rshared' should support propagation from host to container and vice versa
[Fail] [k8s.io] Networking runtime should support networking [It] runtime should support port mapping with host port and container port [Conformance]
[Fail] [k8s.io] Security Context SeccompProfilePath [It] should support seccomp localhost/profile on the container
[Fail] [k8s.io] Container runtime should support log [It] runtime should support starting container with log [Conformance]
[Fail] [k8s.io] Security Context bucket [It] runtime should support RunAsUser
[Fail] [k8s.io] Security Context bucket [It] runtime should support SupplementalGroups
[Fail] [k8s.io] Security Context SeccompProfilePath docker/default [It] should support seccomp docker/default on the container
Signed-off-by: baude <bbaude@redhat.com>
Allows the user to define secret paths in /etc/containers/mounts.conf
These are then volume mounted into the container
Signed-off-by: umohnani8 <umohnani@redhat.com>
Set the exitsdir for kpod back to /var/run/crio... so kpod can benefit
from the container exit file.
Because 0 is the int32 blank value, kpod needs its own container state
struct with the omitempty removed so it can actually display 0 in
its default json output.
Signed-off-by: baude <bbaude@redhat.com>
When running cri-tests with cri-o, I found out that cri-o panicked
immediately with the following message. Fix it by accessing to the
labels map only if it's non-nil.
```
panic: assignment to entry in nil map
goroutine 57 [running]:
.../cri-o/server.(*Server).RunPodSandbox(0xc42048e000, 0x7efcad4cd400,
0xc42066ec90, 0xc4201703d0, 0x0, 0x0, 0x0)
.../cri-o/server/sandbox_run.go:225 +0xda5
.../cri-o/vendor/k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime
._RuntimeService_RunPodSandbox_Handler(0x21793e0, 0xc42048e000,
0x7efcad4cd400, 0xc42066ec90, 0xc4204fe780, 0x0, 0x0, 0x0, 0x0, 0x0)
.../cri-o/vendor/k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime/api.pb.go:3645 +0x279
.../cri-o/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc420
09e3c0, 0x33e79c0, 0xc4203d1950, 0xc42080a000, 0xc4202bb980, 0x33b1d58,
0xc42066ec60, 0x0, 0x0)
.../cri-o/vendor/google.golang.org/grpc/server.go:638 +0x99c
```
Signed-off-by: Dongsu Park <dongsu@kinvolk.io>
server: fix selinux labels for pod and containers
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
sandbox: set selinux labels from request, not defaults
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
container_create: use sandbox's selinux if container's nil
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
sandbox: correctly init selinux labels
First, we weren't correctly initializing selinux labels. If any of
(level, user, role, type) was missing from kube selinux options, we
were erroring out. This is wrong as kube sends just `level=s0`
sometimes and docker itself allows `--security-opt label=level:s0`.
This patch directly initializes selinux labels, correctly, and adds a
test to verify it.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
test: testdata: use container_runtime_t selinux type
RHEL SELinux policy doesn't have `container_t` type but we're using it
in our fixtures. That means Fedora integration tests pass because
`container_t` is in Fedora's container policy but RHEL is broken.
Fix it by using `container_runtime_t` which is aliased in Fedora policy
to `container_t`.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
The inspect endpoint is used mainly in the CRI-O cAdvisor handler.
Let's make sure we don't break it by adding some trivial unit tests.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Kubelet can send cap add/drop ALL. Handle that in CRI-O as well.
Also, this PR is re-vendoring runtime-tools to fix capabilities add to
add caps to _all_ caps set **and** fix a shared memory issue (caps set
were initialized with the same slice, if one modifies one slice, it's
reflected on the other slices, the vendoring fixes this as well)
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Kpod rm removes a container from the system
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: umohnani8 <umohnani@redhat.com>
Add new directory /etc/crio/hooks.d, where packagers can drop a json config
file to specify a hook.
The json must specify a valid executable to run.
The json must also specify which stage(s) to run the hook:
prestart, poststart, poststop
The json must specify under which criteria the hook should be launched
If the container HasBindMounts
If the container cmd matches a list of regular expressions
If the containers annotations matches a list of regular expressions.
If any of these match the the hook will be launched.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
