[Question] rootless seccomp warnings during the build steps

[mo-saeed]

Description

I am using Dind Rootless setup and during the docker build process showing the following warnings and I am not sure if it has any bad impact or a way to fix it

unknown seccomp syscall `close_range` ignored
unknown seccomp syscall `epoll_pwait2` ignored
unknown seccomp syscall `faccessat2` ignored
unknown seccomp syscall `openat2` ignored

Is it sth can be ignored, and if yes is there any way to disable this kind of warnings?

Thanks in advance for help!

Steps to reproduce the issue:
run docker build in rootless Dind setup

Describe the results you received:
docker build succeeded but with unknown syscomp calls

Output of docker version:

docker version
Client: Docker Engine - Community
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:14:11 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:18:31 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          0.12.1
  GitCommit:        df5f2b2369b3d9f36d175e1183b26e5cee55dd0a
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 58
 Server Version: 20.10.5
 Storage Driver: vfs
 Logging Driver: json-file
 Cgroup Driver: none
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc version: df5f2b2369b3d9f36d175e1183b26e5cee55dd0a
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  rootless
 Kernel Version: 5.4.91-41.139.amzn2.x86_64
 Operating System: Ubuntu 20.04.2 LTS (containerized)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.35GiB
 Name: k8s-azure-devops-69cc75fdbf-mp2rz
 ID: 2RGA:ON55:KTAN:LU67:J2BJ:V5L6:Q33W:XPOD:AFOQ:KQCE:FLVV:7SOY
 Docker Root Dir: /azp/.local/share/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

WARNING: Running in rootless-mode without cgroups. To enable cgroups in rootless-mode, you need to boot the system in cgroup v2 mode.

Additional environment details (AWS, VirtualBox, physical, etc.):
Running on kubernetes EKS version 1.19.6

[mo-saeed]

Node kernel version: 5.4.91-41.139.amzn2.x86_64
Dind rootless running on image: ubuntu:20.10

Seccomp enabled on the node: grep CONFIG_SECCOMP= /boot/config-$(uname -r) CONFIG_SECCOMP=y

[thaJeztah]

Is the containerised docker a static build, or installed from a .deb or .rpm package? If it's a static build, it could possibly be related to / addressed by #42054.

Where are the messages appearing? Is that in the daemon logs, the output of the docker build, system logs? (did a quick search in our code for unknown seccomp syscall to find where the message would be generated, but I couldn't find it).

Overall, I think these messages should be safe to ignore; they're likely related to a chicken-and-egg situation where our seccomp profile includes syscalls in the "allow" list, but either libseccomp (and/or the kernel) or the OCI runtime does not yet support those calls, and therefore produces the informational message.

[thaJeztah]

oh; I see you're not running with the default OCI runtime (runc), but with crun instead (based on the version output v0.12.1 and commit; containers/crun@df5f2b2). I see crun has a configuration to either reject such syscalls or to warn only; https://github.com/containers/crun/blob/3cca0b740644ecef4710f8e0c0588e6d40be8434/crun.1.md#runociseccomp_fail_unknown_syscall1

[mo-saeed]

Hi @thaJeztah Thanks for your reply

• it's static build, ubuntu image and installation with https://get.docker.com/rootless.
• it's the output of docker build command inside the DIND rootless container.
• Yes I am using crun instead of runc due to this issue rootless docker in kubernetes: "getting the final child's pid from pipe caused \"EOF\"": unknown" #40068

I am using kubernetes, so the DIND rootless container running in Kubernetes POD, am not sure if this can be an issue.

[thaJeztah]

Yes I am using crun instead of runc due to this issue #40068

Were you still running into that issue with docker 20.10.4 and up? (I know we updated to runc v1.0.0-rc93 in those versions, so mostly curious if that version of runc resolved the issue)

I am using kubernetes, so the DIND rootless container running in Kubernetes POD, am not sure if this can be an issue.

What runtime is kubernetes using on the host? docker? containerd? (and what version?). It's possible that the outer container is created by an older version of either docker or containerd, and because of that using an older seccomp profile that not yet has those syscalls included. In that case the "docker-in-docker" docker (and runc/crun) would not be able to use those syscalls

Actually, I see you're running kernel 5.4, and if I'm not mistaken, faccessat2() is in kernel 5.8 and up (https://man7.org/linux/man-pages/man2/access.2.html), which would probably explain the unknown seccomp syscall warning.

[mo-saeed]

I tried with runc but still the same issue, I am using Dind rootless v20.10.5

Kubernetes host is using docker v19.3.13.

regarding the kernel, ok but what about the other syscalls e.g. close_range ?

[AkihiroSuda]

close_range requires kernel 5.9.
If you are using older kernel there is nothing you can do, and it is harmless unless your application uses that syscall.

[mo-saeed]

I have upgraded crun to the latest version and now messages are gone. Thanks a lot @thaJeztah and @AkihiroSuda.

This can be closed.

[thaJeztah]

I have upgraded crun to the latest version and now messages are gone. Thanks a lot @thaJeztah and @AkihiroSuda.

Good to hear 👍