RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1332369 - Can't successfully start the container with seccomp configuration
Summary: Can't successfully start the container with seccomp configuration
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker-latest
Version: 7.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: gseltzer
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-03 04:11 UTC by Alex Jia
Modified: 2023-09-14 03:21 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-18 14:39:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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
Note You need to log in before you can comment on or make changes to this bug.