Add empty line between "struct file_dedupe_range" definition and the
following paragraph.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The description in the man page is confusing; it makes it sound like
setting the PTRACE_O_EXITKILL flag on any tracee makes it so that all
tracees are killed if the tracer exits. The description from kernel
commit 992fb6e170639b that introduced PTRACE_O_EXITKILL offers a
different explanation: "If the tracer exits it sends SIGKILL to every
tracee which has this bit set".
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
man-pages-1.34 included changes that duplicated an existing
paragraph. Remove that duplicate.
Reported-by: Vincent Bernat <vincent@bernat.im>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A little while back, I added a note to sigprocmask.2 that
discussed the difference between the libc's and the kernel's
sigset_t structures. I added that note, because I saw this being
done wrong in a tool tracing system calls (causing subtle bugs).
As it turns out, the same bugs existed for ppoll and pselect, for
the same reason. I'm hoping by adding the reference here, future
writers of similar tools will find that discussion and not make
the same mistake.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Notes from Eugene:
Based on linux v4.9-rc6 (9c763584):
* security/keys/keyctl.c, SYSCALL_DEFINE4(request_key, ...), line 158:
* Assume that call is performed with with destringid == 0:
* We skip check on line 196, so dest_ref remains NULL
* On line 213, request_key_and_link is called with key_ref_to_ptr(dest_ref)
* key_ref_to_ptr() itself just zeroes lower bit which is used for
indication that key reference in the possession of the current
context.
* security/keys/request_key.c, request_key_and_link, line 508:
* On line 543, we try to search process keyrings for the key (we
fill ctx at hte beginning of the function and then pass it to
search_process_keyrings)
* If key is found (key_ref is not erroneous), we convert key_ref to
ptr on line 546 and skip the following block on line 547 since
dest_keyring is 0.
* If key is not found and error is not EAGAIN, then
construct_key_and_link is called on line 566 with dest_keyring ==
NULL.
* security/keys/request_key.c, construct_key_and_link, line 430:
* On line 450, construct_get_dest_keyring is called with dest_keyring
== NULL.
* security/keys/request_key.c, construct_get_dest_keyring, line 253:
* The argument here (which is pointer to pointer to struct key) is
named _dest_keyring, but on line 257 it is dereferenced to local
variable dest_keyring (so it stores NULL now).
* We re going to the "else" branch (starting from line 266) of check
on line 262
* Now we are switching against cred->jit_keyring with the behavour
described in the patch.
* git grep jit_keyring security/keys reveals that it is assigned inside
keyctl_set_reqkey_keyring, security/keys/keyctl.c, line 1257.
* keyctl_set_reqkey_keyring is called from SYSCALL_DEFINE5(keyctl,
...), when option passed to keyctl is KEYCTL_SET_REQKEY_KEYRING (line
1652).
* Default value for jit_keyring is sort of difficult to find out, since
it is inherited, but overall it is explicitly set to
KEY_REQKEY_DEFL_THREAD_KEYRING or copied from zeroed-out structures
(so it is equal to KEY_REQKEY_DEFL_DEFAULT) which leads to the same
behaviour in case the process has not been upcalled by request_key
construction.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk