Use a single-font-change macro for a single argument.
Remove quotation marks around a single argument (ptrace.2)
The output from "nroff" and "groff" is unchanged, except
1) a font is changed for a punctuation mark (ptrace.2)
2) a comma is moved to the previous line, so the space in front of it
disappears (ptrace.2).
Signed-off-by: Bjarni Ingi Gislason <bjarniig@xxxxxxxxx>
---
man2/pread.2 | 2 +-
man2/process_vm_readv.2 | 24 +++----
man2/ptrace.2 | 148 ++++++++++++++++++++--------------------
3 files changed, 87 insertions(+), 87 deletions(-)
diff --git a/man2/pread.2 b/man2/pread.2
index edd8bb3e9..12a128ec5 100644
--- a/man2/pread.2
+++ b/man2/pread.2
@@ -154,7 +154,7 @@ for the reasons described in
.BR syscall (2).
.SH BUGS
POSIX requires that opening a file with the
-.BR O_APPEND
+.B O_APPEND
flag should have no effect on the location at which
.BR pwrite ()
writes data.
diff --git a/man2/process_vm_readv.2 b/man2/process_vm_readv.2
index 59ad0c178..e6899dd80 100644
--- a/man2/process_vm_readv.2
+++ b/man2/process_vm_readv.2
@@ -58,14 +58,14 @@ Feature Test Macro Requirements for glibc (see
.PD 0
.ad l
.RS 4
-.BR _GNU_SOURCE
+.B _GNU_SOURCE
.RE
.ad
.PD
.SH DESCRIPTION
These system calls transfer data between the address space
of the calling process ("the local process") and the process identified by
-.IR pid
+.I pid
("the remote process").
The data moves directly between the address spaces of the two processes,
without passing through kernel space.
@@ -74,24 +74,24 @@ The
.BR process_vm_readv ()
system call transfers data from the remote process to the local process.
The data to be transferred is identified by
-.IR remote_iov
+.I remote_iov
and
.IR riovcnt :
-.IR remote_iov
+.I remote_iov
is a pointer to an array describing address ranges in the process
.IR pid ,
and
-.IR riovcnt
+.I riovcnt
specifies the number of elements in
.IR remote_iov .
The data is transferred to the locations specified by
-.IR local_iov
+.I local_iov
and
.IR liovcnt :
-.IR local_iov
+.I local_iov
is a pointer to an array describing address ranges in the calling process,
and
-.IR liovcnt
+.I liovcnt
specifies the number of elements in
.IR local_iov .
.PP
@@ -105,7 +105,7 @@ Other than the direction of the transfer, the arguments
.IR local_iov ,
.IR riovcnt ,
and
-.IR remote_iov
+.I remote_iov
have the same meaning as for
.BR process_vm_readv ().
.PP
@@ -116,7 +116,7 @@ and
arguments point to an array of
.I iovec
structures, defined in
-.IR <sys/uio.h>
+.I <sys/uio.h>
as:
.PP
.in +4n
@@ -170,7 +170,7 @@ The values specified in the
and
.I riovcnt
arguments must be less than or equal to
-.BR IOV_MAX
+.B IOV_MAX
(defined in
.I <limits.h>
or accessible via the call
@@ -179,7 +179,7 @@ or accessible via the call
.\" as is done for readv()/writev()
.PP
The count arguments and
-.IR local_iov
+.I local_iov
are checked before doing any transfers.
If the counts are too big, or
.I local_iov
diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 3b6b6ea84..25df15f26 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -197,7 +197,7 @@ isn't expecting to trace it.
.RI ( pid ,
.IR addr ,
and
-.IR data
+.I data
are ignored.)
.IP
The
@@ -251,7 +251,7 @@ to the address
.I addr
in the tracee's memory.
As for
-.BR PTRACE_PEEKTEXT
+.B PTRACE_PEEKTEXT
and
.BR PTRACE_PEEKDATA ,
these two requests are currently equivalent.
@@ -398,7 +398,7 @@ Within the returned
.I siginfo
structures,
the
-.IR si_code
+.I si_code
field includes information
.RB ( __SI_CHLD ,
.BR __SI_FAULT ,
@@ -434,7 +434,7 @@ which should be a pointer to a buffer of type
The
.I addr
argument contains the size of the buffer pointed to by
-.IR data
+.I data
(i.e.,
.IR sizeof(sigset_t) ).
.TP
@@ -448,7 +448,7 @@ which should be a pointer to a buffer of type
The
.I addr
argument contains the size of the buffer pointed to by
-.IR data
+.I data
(i.e.,
.IR sizeof(sigset_t) ).
.TP
@@ -457,7 +457,7 @@ Set ptrace options from
.IR data .
.RI ( addr
is ignored.)
-.IR data
+.I data
is interpreted as a bit mask of options,
which are specified by the following flags:
.RS
@@ -630,7 +630,7 @@ The PID of the new process can (since Linux 2.6.18) be retrieved with
.BR PTRACE_O_TRACESECCOMP " (since Linux 3.5)"
Stop the tracee when a
.BR seccomp (2)
-.BR SECCOMP_RET_TRACE
+.B SECCOMP_RET_TRACE
rule is triggered.
A
.BR waitpid (2)
@@ -643,13 +643,13 @@ value such that
.fi
.IP
While this triggers a
-.BR PTRACE_EVENT
+.B PTRACE_EVENT
stop, it is similar to a syscall-enter-stop.
For details, see the note on
.B PTRACE_EVENT_SECCOMP
below.
The seccomp event message data (from the
-.BR SECCOMP_RET_DATA
+.B SECCOMP_RET_DATA
portion of the seccomp filter rule) can be retrieved with
.BR PTRACE_GETEVENTMSG .
.TP
@@ -663,10 +663,10 @@ before they are installed by the tracee,
let the tracee install the filters,
and then clear this flag when the filters should be resumed.
Setting this option requires that the tracer have the
-.BR CAP_SYS_ADMIN
+.B CAP_SYS_ADMIN
capability,
not have any seccomp protections installed, and not have
-.BR PTRACE_O_SUSPEND_SECCOMP
+.B PTRACE_O_SUSPEND_SECCOMP
set on itself.
.RE
.TP
@@ -692,7 +692,7 @@ For
this is the
.BR seccomp (2)
filter's
-.BR SECCOMP_RET_DATA
+.B SECCOMP_RET_DATA
associated with the triggered rule.
.RI ( addr
is ignored.)
@@ -777,7 +777,7 @@ are ignored.)
.IP
.I This operation is deprecated; do not use it!
Instead, send a
-.BR SIGKILL
+.B SIGKILL
directly using
.BR kill (2)
or
@@ -851,7 +851,7 @@ and
are ignored.)
.IP
Permission to perform a
-.BR PTRACE_ATTACH
+.B PTRACE_ATTACH
is governed by a ptrace access mode
.B PTRACE_MODE_ATTACH_REALCREDS
check; see below.
@@ -911,7 +911,7 @@ must be zero.
contains a bit mask of ptrace options to activate immediately.
.IP
Permission to perform a
-.BR PTRACE_SEIZE
+.B PTRACE_SEIZE
is governed by a ptrace access mode
.B PTRACE_MODE_ATTACH_REALCREDS
check; see below.
@@ -933,7 +933,7 @@ the operation fails with the error
.IP
.I data
is either a pointer to a
-.IR "struct sock_filter"
+.I struct sock_filter
array that is large enough to store the BPF program,
or NULL if the program is not to be stored.
.IP
@@ -942,7 +942,7 @@ the return value is the number of instructions in the BPF program.
If
.I data
was NULL, then this return value can be used to correctly size the
-.IR "struct sock_filter"
+.I struct sock_filter
array passed in a subsequent call.
.IP
This operation fails with the error
@@ -977,7 +977,7 @@ This operation performs a similar task to
It reads the TLS entry in the GDT whose index is given in
.IR addr ,
placing a copy of the entry into the
-.IR "struct user_desc"
+.I struct user_desc
pointed to by
.IR data .
(By contrast with
@@ -985,7 +985,7 @@ pointed to by
the
.I entry_number
of the
-.IR "struct user_desc"
+.I struct user_desc
is ignored.)
.TP
.BR PTRACE_SET_THREAD_AREA " (since Linux 2.6.0)"
@@ -994,7 +994,7 @@ This operation performs a similar task to
It sets the TLS entry in the GDT whose index is given in
.IR addr ,
assigning it the data supplied in the
-.IR "struct user_desc"
+.I struct user_desc
pointed to by
.IR data .
(By contrast with
@@ -1002,7 +1002,7 @@ pointed to by
the
.I entry_number
of the
-.IR "struct user_desc"
+.I struct user_desc
is ignored; in other words,
this ptrace operation can't be used to allocate a free TLS entry.)
.\"
@@ -1109,7 +1109,7 @@ etc.)
is nevertheless considered to be running, even if the tracee is blocked
for a long time.
The state of the tracee after
-.BR PTRACE_LISTEN
+.B PTRACE_LISTEN
is somewhat of a gray area: it is not in any ptrace-stop (ptrace commands
won't work on it, and it will deliver
.BR waitpid (2)
@@ -1321,7 +1321,7 @@ a group-stopped process.
This side effect happens before signal-delivery-stop.
The tracer can't suppress this side effect (it can
only suppress signal injection, which only causes the
-.BR SIGCONT
+.B SIGCONT
handler to not be executed in the tracee, if such a handler is installed).
In fact, waking up from group-stop may be followed by
signal-delivery-stop for signal(s)
@@ -1515,14 +1515,14 @@ but after the child unblocked this tracee by exiting or execing.
For all four stops described above,
the stop occurs in the parent (i.e., the tracee),
not in the newly created thread.
-.BR PTRACE_GETEVENTMSG
+.B PTRACE_GETEVENTMSG
can be used to retrieve the new thread's ID.
.TP
.B PTRACE_EVENT_EXEC
Stop before return from
.BR execve (2).
Since Linux 3.0,
-.BR PTRACE_GETEVENTMSG
+.B PTRACE_GETEVENTMSG
returns the former thread ID.
.TP
.B PTRACE_EVENT_EXIT
@@ -1552,10 +1552,10 @@ command, or group-stop, or initial ptrace-stop when a new child is attached
Stop triggered by a
.BR seccomp (2)
rule on tracee syscall entry when
-.BR PTRACE_O_TRACESECCOMP
+.B PTRACE_O_TRACESECCOMP
has been set by the tracer.
The seccomp event message data (from the
-.BR SECCOMP_RET_DATA
+.B SECCOMP_RET_DATA
portion of the seccomp filter rule) can be retrieved with
.BR PTRACE_GETEVENTMSG .
The semantics of this stop are described in
@@ -1574,7 +1574,7 @@ set to
.IR "(event<<8)\ |\ SIGTRAP" .
.SS Syscall-stops
If the tracee was restarted by
-.BR PTRACE_SYSCALL
+.B PTRACE_SYSCALL
or
.BR PTRACE_SYSEMU ,
the tracee enters
@@ -1596,13 +1596,13 @@ If the tracee is continued using any other method (including
.BR PTRACE_SYSEMU ),
no syscall-exit-stop occurs.
Note that all mentions
-.BR PTRACE_SYSEMU
+.B PTRACE_SYSEMU
apply equally to
-.BR PTRACE_SYSEMU_SINGLESTEP.
+.B PTRACE_SYSEMU_SINGLESTEP.
.PP
However, even if the tracee was continued using
-.BR PTRACE_SYSCALL
-, it is not guaranteed that the next stop will be a syscall-exit-stop.
+.BR PTRACE_SYSCALL ,
+it is not guaranteed that the next stop will be a syscall-exit-stop.
Other possibilities are that the tracee may stop in a
.B PTRACE_EVENT
stop (including seccomp stops), exit (if it entered
@@ -1635,7 +1635,7 @@ will give the value
Syscall-stops can be distinguished from signal-delivery-stop with
.B SIGTRAP
by querying
-.BR PTRACE_GETSIGINFO
+.B PTRACE_GETSIGINFO
for the following cases:
.TP
.IR si_code " <= 0"
@@ -1725,7 +1725,7 @@ or
.\"
.SS PTRACE_EVENT_SECCOMP stops (Linux 3.5 to 4.7)
The behavior of
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
stops and their interaction with other kinds
of ptrace stops has changed between kernel versions.
This documents the behavior
@@ -1733,30 +1733,30 @@ from their introduction until Linux 4.7 (inclusive).
The behavior in later kernel versions is documented in the next section.
.PP
A
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
stop occurs whenever a
-.BR SECCOMP_RET_TRACE
+.B SECCOMP_RET_TRACE
rule is triggered.
This is independent of which methods was used to restart the system call.
Notably, seccomp still runs even if the tracee was restarted using
-.BR PTRACE_SYSEMU
+.B PTRACE_SYSEMU
and this system call is unconditionally skipped.
.PP
Restarts from this stop will behave as if the stop had occurred right
before the system call in question.
In particular, both
-.BR PTRACE_SYSCALL
+.B PTRACE_SYSCALL
and
-.BR PTRACE_SYSEMU
+.B PTRACE_SYSEMU
will normally cause a subsequent syscall-entry-stop.
However, if after the
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
the system call number is negative,
both the syscall-entry-stop and the system call itself will be skipped.
This means that if the system call number is negative after a
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
and the tracee is restarted using
-.BR PTRACE_SYSCALL,
+.BR PTRACE_SYSCALL ,
the next observed stop will be a syscall-exit-stop,
rather than the syscall-entry-stop that might have been expected.
.\"
@@ -1764,7 +1764,7 @@ rather than the syscall-entry-stop that might have been expected.
Starting with Linux 4.8,
.\" commit 93e35efb8de45393cf61ed07f7b407629bf698ea
the
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
stop was reordered to occur between syscall-entry-stop and
syscall-exit-stop.
Note that seccomp no longer runs (and no
@@ -1776,7 +1776,7 @@ Functionally, a
.B PTRACE_EVENT_SECCOMP
stop functions comparably
to a syscall-entry-stop (i.e., continuations using
-.BR PTRACE_SYSCALL
+.B PTRACE_SYSCALL
will cause syscall-exit-stops,
the system call number may be changed and any other modified registers
are visible to the to-be-executed system call as well).
@@ -1784,13 +1784,13 @@ Note that there may be,
but need not have been a preceding syscall-entry-stop.
.PP
After a
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
stop, seccomp will be rerun, with a
-.BR SECCOMP_RET_TRACE
+.B SECCOMP_RET_TRACE
rule now functioning the same as a
.BR SECCOMP_RET_ALLOW .
Specifically, this means that if registers are not modified during the
-.BR PTRACE_EVENT_SECCOMP
+.B PTRACE_EVENT_SECCOMP
stop, the system call will then be allowed.
.\"
.SS PTRACE_SINGLESTEP stops
@@ -1851,7 +1851,7 @@ Flags are inherited by new tracees created and "auto-attached" via active
.BR PTRACE_O_TRACEFORK ,
.BR PTRACE_O_TRACEVFORK ,
or
-.BR PTRACE_O_TRACECLONE
+.B PTRACE_O_TRACECLONE
options.
.PP
Another group of commands makes the ptrace-stopped tracee run.
@@ -1950,7 +1950,7 @@ If the
.BR PTRACE_O_TRACEFORK ,
.BR PTRACE_O_TRACEVFORK ,
or
-.BR PTRACE_O_TRACECLONE
+.B PTRACE_O_TRACECLONE
options are in effect, then children created by, respectively,
.BR vfork (2)
or
@@ -2036,7 +2036,7 @@ This resetting of the thread ID looks very confusing to tracers:
All other threads stop in
.B PTRACE_EVENT_EXIT
stop, if the
-.BR PTRACE_O_TRACEEXIT
+.B PTRACE_O_TRACEEXIT
option was turned on.
Then all other threads except the thread group leader report
death as if they exited via
@@ -2054,7 +2054,7 @@ which is the same as the thread group leader's thread ID.
Then a
.B PTRACE_EVENT_EXEC
stop happens, if the
-.BR PTRACE_O_TRACEEXEC
+.B PTRACE_O_TRACEEXEC
option was turned on.
.IP *
If the thread group leader has reported its
@@ -2085,7 +2085,7 @@ The
.B PTRACE_O_TRACEEXEC
option is the recommended tool for dealing with this situation.
First, it enables
-.BR PTRACE_EVENT_EXEC
+.B PTRACE_EVENT_EXEC
stop,
which occurs before
.BR execve (2)
@@ -2328,7 +2328,7 @@ Since Linux 2.6.27,
.\" commit 006ebb40d3d65338bd74abb03b945f8d60e362bd
two access mode levels are distinguished:
.TP
-.BR PTRACE_MODE_READ
+.B PTRACE_MODE_READ
For "read" operations or other operations that are less dangerous,
such as:
.BR get_robust_list (2);
@@ -2341,10 +2341,10 @@ or
or
.BR readlink (2)
of a
-.IR /proc/[pid]/ns/*
+.I /proc/[pid]/ns/*
file.
.TP
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
For "write" operations, or other operations that are more dangerous,
such as: ptrace attaching
.RB ( PTRACE_ATTACH )
@@ -2418,7 +2418,7 @@ This modifier suppresses the generation of
such an audit record for the particular access check.
.PP
Note that all of the
-.BR PTRACE_MODE_*
+.B PTRACE_MODE_*
constants described in this subsection are kernel-internal,
and not visible to user space.
The constant names are mentioned here in order to label the various kinds of
@@ -2432,7 +2432,7 @@ The algorithm employed for ptrace access mode checking determines whether
the calling process is allowed to perform the corresponding action
on the target process.
(In the case of opening
-.IR /proc/[pid]
+.I /proc/[pid]
files, the "calling process" is the one opening the file,
and the process with the corresponding PID is the "target process".)
The algorithm is as follows:
@@ -2454,7 +2454,7 @@ Otherwise, the access mode specifies
so use the caller's real UID and GID for the checks in the next step.
(Most APIs that check the caller's UID and GID use the effective IDs.
For historical reasons, the
-.BR PTRACE_MODE_REALCREDS
+.B PTRACE_MODE_REALCREDS
check uses the real IDs instead.)
.IP 3.
Deny access if
@@ -2464,7 +2464,7 @@ of the following is true:
.IP \(bu 2
The real, effective, and saved-set user IDs of the target
match the caller's user ID,
-.IR and
+.I and
the real, effective, and saved-set group IDs of the target
match the caller's group ID.
.IP \(bu
@@ -2476,11 +2476,11 @@ capability in the user namespace of the target.
Deny access if the target process "dumpable" attribute has a value other than 1
.RB ( SUID_DUMP_USER ;
see the discussion of
-.BR PR_SET_DUMPABLE
+.B PR_SET_DUMPABLE
in
.BR prctl (2)),
and the caller does not have the
-.BR CAP_SYS_PTRACE
+.B CAP_SYS_PTRACE
capability in the user namespace of the target process.
.IP 5.
The kernel LSM
@@ -2553,7 +2553,7 @@ and thus expand the scope of the attack.
More precisely, the Yama LSM limits two types of operations:
.IP * 3
Any operation that performs a ptrace access mode
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
check\(emfor example,
.BR ptrace ()
.BR PTRACE_ATTACH .
@@ -2566,21 +2566,21 @@ check\(emfor example,
A process that has the
.B CAP_SYS_PTRACE
capability can update the
-.IR /proc/sys/kernel/yama/ptrace_scope
+.I /proc/sys/kernel/yama/ptrace_scope
file with one of the following values:
.TP
0 ("classic ptrace permissions")
No additional restrictions on operations that perform
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
checks (beyond those imposed by the commoncap and other LSMs).
.IP
The use of
-.BR PTRACE_TRACEME
+.B PTRACE_TRACEME
is unchanged.
.TP
1 ("restricted ptrace") [default value]
When performing an operation that requires a
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
check, the calling process must either have the
.B CAP_SYS_PTRACE
capability in the user namespace of the target process or
@@ -2593,31 +2593,31 @@ A target process can employ the
.BR prctl (2)
.B PR_SET_PTRACER
operation to declare an additional PID that is allowed to perform
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
operations on the target.
See the kernel source file
-.IR Documentation/admin\-guide/LSM/Yama.rst
+.I Documentation/admin\-guide/LSM/Yama.rst
.\" commit 90bb766440f2147486a2acc3e793d7b8348b0c22
(or
-.IR Documentation/security/Yama.txt
+.I Documentation/security/Yama.txt
before Linux 4.13)
for further details.
.IP
The use of
-.BR PTRACE_TRACEME
+.B PTRACE_TRACEME
is unchanged.
.TP
2 ("admin-only attach")
Only processes with the
.B CAP_SYS_PTRACE
capability in the user namespace of the target process may perform
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
operations or trace children that employ
.BR PTRACE_TRACEME .
.TP
3 ("no attach")
No process may perform
-.BR PTRACE_MODE_ATTACH
+.B PTRACE_MODE_ATTACH
operations or trace children that employ
.BR PTRACE_TRACEME .
.IP
@@ -2642,7 +2642,7 @@ At the system call level, the
.BR PTRACE_PEEKTEXT ,
.BR PTRACE_PEEKDATA ,
and
-.BR PTRACE_PEEKUSER
+.B PTRACE_PEEKUSER
requests have a different API: they store the result
at the address specified by the
.I data
@@ -2771,7 +2771,7 @@ by checking the current time, and then executing
.BR epoll_wait (2)
again.
(Programs which do not expect such "stray"
-.BR EINTR
+.B EINTR
errors may behave in an unintended way upon an
.BR strace (1)
attach.)
--
2.20.1
