Use systemd's sd_notify with option up_sdnotify

[cognifloyd]

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.

Resolves #70

[paulusmack]

Mostly looks good. Two comments:

1. Could you please add a Signed-off-by to the commit message?

2. What happens if a non-privileged user running pppd specifies the up_sdnotify option? Does sd_notify do anything bad if it is called when pppd was not run from systemd? Is there any way that this could let a non-privileged user attack systemd and possibly gain privileges somehow?

[cognifloyd]

1. I'll add that sometime next week. 2. Systemd services can be running as --system or --user services. I have not tested ruining ppp as a non root user, but it shouldn't matter how the service is running (system vs user) or which user it is running as. Also, systemd is very strict about listening for and acting on notifications from processes that are allowed to do so. If systemd didn't start the process, it ignores any notifications unless the signaling process was started by a service that systemd is monitoring (directly or indirectly, such as a grand child 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. Side note: when a child process seems the notification instead of the actual service process, there are some nasty race conditions that can cause systemd to ignore the notification even if that child process is allowed to send (eg the process excited before systems could look up its parents and cgroup). Plus, if you run systemd-notify, a command line utility that seems the notification, from within ip-up out one of ip-up's children, then the notification never succeeds. First there's the race condition of those scripts being too short lived. Then, ip-up's environment is so effectively sanitized that even if I somehow set the environment variable that systemd-notify expects, it still never succeeds in associating the notification with service. So, systemd is really good at ignoring notifications unless it expects them, and the only really reliable way to send those signals is from the actual non-daemonizing service process. 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. On Sat, Mar 25, 2017, 21:57 Paul Mackerras <[email protected]> wrote: Mostly looks good. Two comments: 1. Could you please add a Signed-off-by to the commit message? 2. What happens if a non-privileged user running pppd specifies the up_sdnotify option? Does sd_notify do anything bad if it is called when pppd was not run from systemd? Is there any way that this could let a non-privileged user attack systemd and possibly gain privileges somehow? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#79 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfIPhnrgCod-L8zaGwtn9dcKyiX8Bppks5rpdQdgaJpZM4MosAv> .

[paulusmack]

OK, sounds fair.

Please add a paragraph to the commit message explaining that you have made the new option a non-privileged option because ... (e.g., because a non-privileged user running pppd can't cause any disruption by setting it, and briefly why that is so).

[cognifloyd]

OK. I finally got around to fixing the commit message.