If you have a
daemon:notify app, it won’t work outside of devmode because nothing gives it permission to talk to
If you have a
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.
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.