mirror of
https://github.com/systemd/systemd.git
synced 2025-03-19 22:50:17 +03:00
man: Clarify systemd-notify and sd_notify() PID documentation
Let's clarify more explicitly that privileged calls to systemd-notify --pid= and sd_pid_notify() effectively override any configured NotifyAccess=main|exec for a service. (cherry picked from commit bbe9e03f8066d1001497494ee862cf45f986b854)
This commit is contained in:
parent
b1fe0a92eb
commit
9b186fc8bc
@ -140,9 +140,12 @@
|
||||
<para><function>sd_pid_notify()</function> and <function>sd_pid_notifyf()</function> are similar to
|
||||
<function>sd_notify()</function> and <function>sd_notifyf()</function> but take a process ID (PID) to use
|
||||
as originating PID for the message as first argument. This is useful to send notification messages on
|
||||
behalf of other processes, provided the appropriate privileges are available. If the PID argument is
|
||||
specified as 0, the process ID of the calling process is used, in which case the calls are fully
|
||||
equivalent to <function>sd_notify()</function> and <function>sd_notifyf()</function>.</para>
|
||||
behalf of other processes, provided the appropriate privileges are available. Effectively, this means
|
||||
that a privileged invocation of <command>sd_pid_notify()</command> may circumvent
|
||||
<varname>NotifyAccess=main</varname> or <varname>NotifyAccess=exec</varname> restrictions enforced for a
|
||||
service. If the PID argument is specified as 0, the process ID of the calling process is used, in which
|
||||
case the calls are fully equivalent to <function>sd_notify()</function> and
|
||||
<function>sd_notifyf()</function>.</para>
|
||||
|
||||
<para><function>sd_pid_notify_with_fds()</function> is similar to <function>sd_pid_notify()</function>
|
||||
but takes an additional array of file descriptors. These file descriptors are sent along the notification
|
||||
|
@ -125,12 +125,19 @@
|
||||
argument is specified as <literal>self</literal>, the PID of the <command>systemd-notify</command>
|
||||
command itself is used, and if <literal>parent</literal> is specified the calling process' PID is
|
||||
used — even if it is the service manager. <option>--pid=auto</option> is equivalent to <command>systemd-notify
|
||||
MAINPID=$PID</command>. For details about the semantics of this option see
|
||||
--pid=$PID</command>. For details about the semantics of this option see
|
||||
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>If this switch is used in an <command>systemd-notify</command> invocation from a process that
|
||||
shall become the new main process of a service — and which is not the process forked off by the
|
||||
service manager (or the current main process) —, then it is essential to set
|
||||
<para><command>systemd-notify</command> will first attempt to invoke <function>sd_notify()</function>
|
||||
pretending to have the PID specified with <option>--pid=</option>. This will only succeed when
|
||||
invoked with sufficient privileges. On failure, it will then fall back to invoking it under its own
|
||||
PID. Effectively, this means that a privileged invocation of <command>systemd-notify --pid=</command>
|
||||
may circumvent <varname>NotifyAccess=main</varname> or <varname>NotifyAccess=exec</varname>
|
||||
restrictions enforced for a service.</para>
|
||||
|
||||
<para>If this switch is used in an unprivileged <command>systemd-notify</command> invocation from a
|
||||
process that shall become the new main process of a service — and which is not the process forked off
|
||||
by the service manager (or the current main process) —, then it is essential to set
|
||||
<varname>NotifyAccess=all</varname> in the service unit file, or otherwise the notification will be
|
||||
ignored for security reasons. See
|
||||
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
|
Loading…
x
Reference in New Issue
Block a user