Use systemd's sd_notify with option up_sdnotify

This adds an up_sdnotify option so that systemd services of
Type=notify can have pppd send the READY=1 signal to systemd
once a network protocol (typically IP) is up.

To use up_sdnotify, pppd must be compiled with SYSTEMD=y.

up_sdnotify is safe as a non-priveleged option because systemd will
ignore any notifications that it is not expecting. If systemd starts
pppd in a unit-file that is Type=notify, then (and only then) will it
handle the READY=1 signal. If systemd didn't start the process, it
ignroes any notifications unless the signaling process was started by a
service that systemd is monitoring (directly or indirectly, such as a
grandchild process in the same cgroup as a process that systemd started)
AND that service is Type=notify, AND that service is explicitly
configured to allow other processes to send a notification on behalf of
that service by setting NotifyAccess=all.

Also, the socket used is defined in an environment variable provided and
deleted by systemd, allowing system and user services to use a different
socket. I really don't think there's any way to use that socket (even via
the sd_notify api of their library) to gain elevated privileges.

Another reason that up_sdnotify is a non-priveleged option is for cases
where ppp should be started as a system service under a non-priveleged
account. There may be other issues with running ppp under other
accounts, but systemd does not require root--or other privileged--access
in order to use the notification feature. Instead the security for this
feature is provided at the process level in that systemd knows which
processes it did and did not start, and which processes those processes
started (ie other processes in the systemd unit's cgroup), as explained
above.

Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>

0 files changed, 0 insertions, 0 deletions