Bug 1332369

Summary:	Can't successfully start the container with seccomp configuration
Product:	Red Hat Enterprise Linux 7	Reporter:	Alex Jia <ajia>
Component:	docker-latest	Assignee:	gseltzer <gseltzer>
Status:	CLOSED NOTABUG	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.4	CC:	amurdaca, dwalsh, gseltzer, mheon
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-18 14:39:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alex Jia 2016-05-03 04:11:27 UTC

Description of problem:
As summary, in addition, the exit code is 0 when got "Error resolving syscall name copy_file_range" w/ registry.access.redhat.com/rhel7:latest(1a9b3357bac5)

Version-Release number of selected component (if applicable):
# rpm -q docker-latest libseccomp libseccomp-devel
docker-latest-1.10.3-19.el7.x86_64
libseccomp-2.3.1-2.el7.x86_64
libseccomp-devel-2.3.1-2.el7.x86_64


How reproducible:
always

Steps to Reproduce:
1. curl -O https://raw.githubusercontent.com/docker/docker/master/profiles/seccomp/default.json
2. docker-latest run --security-opt seccomp:`pwd`/default.json rhel7 /bin/bash
3. echo $?
4. docker-latest ps

Actual results:

# docker-latest run --security-opt seccomp:`pwd`/default.json registry.access.redhat.com/rhel7 /bin/bash
Unable to find image 'registry.access.redhat.com/rhel7:latest' locally
Trying to pull repository registry.access.redhat.com/rhel7 ... 
Pulling repository registry.access.redhat.com/rhel7
95612a3264fc: Pull complete 
Status: Downloaded newer image for registry.access.redhat.com/rhel7:latest
registry.access.redhat.com/rhel7: this image was pulled from a legacy registry.  Important: This registry version will not be supported in future versions of docker.
2016/05/03 00:00:50 Error resolving syscall name copy_file_range: could not resolve name to syscall - ignoring syscall.

# echo $?
0

NOTE: is it an expected error? and exit code should be non zero.


Removing copy_file_range related 5 lines from default.json and run again.

# docker-latest run --security-opt seccomp:`pwd`/default.json registry.access.redhat.com/rhel7 /bin/bash

# echo $?
0

# docker-latest ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
                    tender_einstein

Additional info:

# docker-latest ps -a
CONTAINER ID        IMAGE                              COMMAND             CREATED             STATUS                      PORTS               NAMES
6cd15b8e71dd        registry.access.redhat.com/rhel7   "/bin/bash"         9 seconds ago       Exited (0) 8 seconds ago    

# docker-latest logs 6cd15b8e71dd
Expected results:

NOTE: nothing output

Comment 2 Antonio Murdaca 2016-06-03 20:45:36 UTC

gseltzer - need to report this upstream if you can repro - ping me if you need any further help with this

Comment 5 Daniel Walsh 2016-10-18 13:22:56 UTC

Matt can you take a look at this bug?

Comment 6 Matthew Heon 2016-10-18 14:37:45 UTC

This isn't actually an error, just a warning. Some system calls are not present in certain kernel versions or architectures, and libseccomp cannot block a syscall that does not exist. Docker's Seccomp implementation does not consider this an error, because the same end result occurs - the 'copy_file_range' syscall cannot be made. We print the warning because this could also mean that the syscall exists, but there was a typo in its name (for example, 'copyf_ile_range' instead of 'copy_file_range'). In this case, 'copy_file_range' is a very recent syscall, and a cursory investigation suggests it is not in RHEL7's kernel - so this appears to be expected behavior.

The test of the warning itself could probably use tweaking to make sure customers know this is not something to be particularly concerned about, though they should check the spelling on the syscall name to be sure.

This would be a bug if the container is actually failing to create. This is just a warning, so we should be printing that information only, not failing to create a container.

Comment 7 Red Hat Bugzilla 2023-09-14 03:21:54 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days