Bug 1177724
| Summary: | BUG: libseccomp man pages use the term "process" in many places where it should read "thread" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Luyao Huang <lhuang> |
| Component: | libseccomp | Assignee: | Paul Moore <pmoore> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | dyuan, huding, juzhang, michen, mzhan, pmoore, weliao, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libseccomp-2.2.1-0.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-19 10:49:34 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: | |||
This has been corrected upstream with the following commit and will be included in the next libseccomp release: https://github.com/seccomp/libseccomp/commit/00a8d27439b5749b7b62f8210fb1eb5a05ca0a13 A new libseccomp release, v2.2.0, fixes this problem upstream: * https://groups.google.com/forum/#!topic/libseccomp/vOem_SXoDp8 Fix included in RHBZ #1100904. Hi, Paul:
from man of libseccomp,I saw "If the thread is being traced and the tracing process specified the PTRACE_O_TRACESECCOMP option in the call to ptrace(2), the tracing process will be notified, via PTRACE_EVENT_SECCOMP , and
the value provided in msg_num can be retrieved using the PTRACE_GETEVENTMSG option." --- Here "tracing process" and "tracing process" need change to "thread" ?
Version-Release number of selected component (if applicable):
libseccomp-devel-2.2.1-1.el7.x86_64
man seccomp_init
SCMP_ACT_KILL
The thread will be killed by the kernel when it calls a syscall that does not match any of the configured seccomp filter rules.
SCMP_ACT_TRAP
The thread will throw a SIGSYS signal when it calls a syscall that does not match any of the configured seccomp filter rules.
SCMP_ACT_ERRNO(uint16_t errno)
The thread will receive a return value of errno when it calls a syscall that does not match any of the configured seccomp filter rules.
SCMP_ACT_TRACE(uint16_t msg_num)
If the thread is being traced and the tracing process specified the PTRACE_O_TRACESECCOMP option in the call to ptrace(2), the tracing process will be notified, via PTRACE_EVENT_SECCOMP , and
the value provided in msg_num can be retrieved using the PTRACE_GETEVENTMSG option.
That text, as written in the manpage, looks correct to me. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2321.html |
Description of problem: improve the manual of seccomp_init about "the process" Version-Release number of selected component (if applicable): libseccomp-2.1.1-2.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.# man seccomp_init ... SCMP_ACT_KILL The process will be killed by the kernel when it calls a syscall that does not match any of the configured seccomp filter rules. SCMP_ACT_TRAP The process will throw a SIGSYS signal when it calls a syscall that does not match any of the configured seccomp filter rules. SCMP_ACT_ERRNO(uint16_t errno) The process will receive a return value of errno when it calls a syscall that does not match any of the configured seccomp filter rules. ... 2. 3. Actual results: from man of libseccomp , it said "the process will be killed" after i do some test and check the manual of prctl(), i think it should be "the thread" Expected results: should give a more clearly manual for libseccomp Additional info: # man prctl PR_SET_SECCOMP (since Linux 2.6.23) Set the secure computing (seccomp) mode for the calling thread, to limit the available system calls. The seccomp mode is selected via arg2. (The seccomp constants are defined in <linux/sec‐ comp.h>.) With arg2 set to SECCOMP_MODE_STRICT the only system calls that the thread is permitted to make are read(2), write(2), _exit(2), and sigreturn(2). Other system calls result in the delivery of a SIGKILL signal. Strict secure computing mode is useful for number-crunching applications that may need to execute untrusted byte code, perhaps obtained by reading from a pipe or socket. This operation is available only if the kernel is configured with CONFIG_SECCOMP enabled. With arg2 set to SECCOMP_MODE_FILTER (since Linux 3.5) the system calls allowed are defined by a pointer to a Berkeley Packet Filter passed in arg3. This argument is a pointer to struct sock_fprog; it can be designed to filter arbitrary system calls and system call arguments. This mode is available only if the kernel is configured with CONFIG_SECCOMP_FILTER enabled. If SECCOMP_MODE_FILTER filters permit fork(2), then the seccomp mode is inherited by children created by fork(2); if execve(2) is permitted, then the seccomp mode is preserved across execve(2). If the filters permit prctl() calls, then additional filters can be added; they are run in order until the first non-allow result is seen. For further information, see the kernel source file Documentation/prctl/seccomp_filter.txt.