If you have a daemon:notify app, it won’t work outside of devmode because nothing gives it permission to talk to /run/systemd/notify.
5 Likes
Reading the manual page, it looks like systemd already controls access to this socket regardless through the NotifyAccess parameter, so this may probably be added to the base template.
NotifyAccess should be all for those daemons, given common practices around snap daemons.
Please request me as a reviewer for this PR.
3 Likes
Any news so far or is there any work-around for this problem?
If you add a daemon-notify plug and ensure it is connected, it should allow access to the notify socket.
The interface does not auto-connect by default, so you’d need to request auto-connection here on the forum. Perhaps it is worth revisiting that default in the policy.
Unfortunately there is a bit of history around daemon-notify support in snapd, and it’s implementation is more insecure than we would like so we can’t enable it for any snap generically, but I think the reviewers are pretty easy to convince to provide it to snaps that need it if you wanted to request auto-connection for your snap. The other wrinkle is that the READY message needs to be sent by the same PID that systemd is tracking, we cannot add policy for the feature that allows systemd-notify to “impersonate” another PID
Looking at the systemd code, the ability to send a notify message on behalf of another process is done by passing an SCM_CREDENTIALS ancillary message with the status message.
According to the unix(7) man page, a process can only send a pid other than its own in the credentials message if it has the CAP_SYS_ADMIN capability. While we do have some interfaces that grant that capability to snaps, in general snapped system daemons won’t have it.
I wonder if we were overestimating the danger of this access?
This was Jamie’s comment at the time, https://github.com/snapcore/snapd/pull/6697#issuecomment-528987808
I had forgotten that he said it’s possible it could be included but was in a part of systemd that has historically been subject to CVE’s so needed a deep audit before granting it
I guess the MAINPID notify command could also be a problem: it looks like it special cases uid==0 to allow root to change the main pid of a service to anything, rather than limiting it to the service’s cgroup.