From: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org
To: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [Bug 134971] New: Clarify kill(2) man-page for permission to "send" signal 0
Date: Fri, 15 Jul 2016 02:50:30 +0000 [thread overview]
Message-ID: <bug-134971-11311@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=134971
Bug ID: 134971
Summary: Clarify kill(2) man-page for permission to "send"
signal 0
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: man-pages
Assignee: documentation_man-pages-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
Reporter: jrw32982-/E1597aS9LQAvxtiuMwx3w@public.gmane.org
Regression: No
The description of errors relating to signal 0 leaves room for
misinterpretation.
The kill(2) man-page says that for signal 0, no signal is sent, mentions that
error checking is performed and that signal 0 can be used to check for process
existence. Then it says the a process must have perms to send a signal.
Later, for EPERM, it says that the process doesn't have perms to send the
signal.
But for signal 0, no signal is sent. What's not 100% clear is that, *even for
signal 0*, a process must have perms (CAP_KILL or matching user ID). I
misinterpreted it to mean that any process could send signal 0 to any other
process (regardless of user ID), but could not send a non-zero signal to a
process without the appropriate perms. But this is wrong. The reason for the
confusion is the word "send/sent" not being used 100% consistently.
Maybe the wording could be enhanced to say "For a process to have permission to
send a signal, including signal 0, it must either be ...".
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2016-07-15 2:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 2:50 bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r [this message]
[not found] ` <bug-134971-11311-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
2016-07-16 10:24 ` [Bug 134971] Clarify kill(2) man-page for permission to "send" signal 0 bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2016-07-16 13:12 ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-134971-11311@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon-590eeb7gvniway/ihj7yzeb+6bgklq7r@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.