* data/systemd/snapd.service: use RestartMode=direct
Systemd 254 introduced a new behavior, when the a service during automatic
restart goes through the failed/inactive state such that OnFailure/OnSuccess
dependencies get triggered. In previous releases those dependencies would only
be triggered when the unit has failed to active (or finished). This results in
an unexpected behavior when the snapd.failure.service is invoked at runtime
without an ongoing snapd refresh. Snap-failure starts the snapd binary from the
previous revision of the snapd snap, but since there was no snap change in
progress, snapd just continues to run however with the parent process being
snap-failure instead of systemd. Setting RestartMode=direct brings back the old
behavior when service was automatically restarted.
See e67129e5e4/NEWS (L1796-L1801)
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/core/snapd-failover: verify snapd process cgroup (and hence systemd unit)
Make sure that snapd process is running within the context of the snapd.service
unit.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/core/snapd-failover: update log match to catch the right event
Update the test to look for a log that actually matches what is logged in the
system. Specifically `Starting...` is logged when the unit gets activated, while
`Started..` when the unit completed activation. In case of one-shot units, the
'starting' log comes first, while 'started' is logged after the unit has become
active.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/core/snapd-failover: encode systemd unit failure behavior in the test
When running the test on UC6, verify that snapd.failure.service was indeed
triggered in the simplest scenario.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Since 3cfa28a0fc snap-confine checks if the system is running in a container. It
does so by reading /run/systemd/container. Extend the SELinux to allow basic
search operations within /run/systemd. It is unlikely anyone runs snapd in a
container where the SELinux is enabled on the host, so the actual file read
permissions are likely not needed.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Allow all service's control group processes to send notifications via
sd_notify. This is necesssary to prevent log flooding with systemd
warnings like:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification
message from PID 1002, but reception only permitted for main PID 917
This warnings are happening due to a change in systemd 254 that makes
all systemd programs (systemctl, udevadm, systemd-detect-virt, etc.)
send EXIT_STATUS notifications when exiting.
Fixes LP#2060310.
Make sure that /snap/snapd/current is set before executing any binary
from snapd snap.
We will rely on `/snap/snapd/current/lib64/ld-linux.so.2` (varies
depending on architecture) being available to execute binaries from
the snap. So the symlink has to be set before we restart services.
* data/selinux: add missing polkitd type for snappy_cli_t
* data/selinux: fix indentation
* data/selinux: allow snapd to poke polkitd as well
* data/selinux: be consistent in order
In case of re-execution, snapd snap has to be
mounted. apparmor.service has a dependency to local-fs.target which is
enough in theory. But in case this dependency dispappears, it is
better to have an explicit dependency to snapd.mount.target in the
unit.
The selinux-clean test started failing in fedora and centos recently.
It is caused by a change in the polkit_agent interface where now the
polkit-agent-helper-1 is located here
/usr/lib{exec,/polkit-1}/polkit-agent-helper-1
The change has been introduced in:
https://github.com/snapcore/snapd/pull/13261
The denial produced is the following:
type=AVC msg=audit(1698154354.527:12577): avc: denied { getattr } for
pid=82525 comm="snapd" path="/usr/lib/polkit-1/polkit-agent-helper-1"
dev="sda5" ino=109823 scontext=system_u:system_r:snappy_t:s0
tcontext=system_u:object_r:policykit_auth_exec_t:s0 tclass=file
permissive=1
Update the selinux policy to fix the denial which is shown in centos 7
type=AVC msg=audit(09/26/23 12:44:11.492:315) : avc: denied { rename }
for pid=28207 comm=snapd name=lxd.lxc.yLBQbN9J4LrW~ dev="sda2"
ino=17679133 scontext=system_u:system_r:snappy_t:s0
tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file permissive=1
* data: fix snapd.aa-prompt-ui.service to actually get started
The current snapd.aa-prompt-ui.service user service is dbus activated.
However this does not work with the latest prompt design.
* packaing: add snapd.aa-prompt-ui.service to auto-start
This is required by upower-observe interface.
Some tests are failing in centos and fedora after the
upowerObserveInterface was update in this way.
func (iface *upowerObserveInterface) StaticInfo() interfaces.StaticInfo
{
...
ImplicitOnCore:
osutil.IsExecutable("/usr/libexec/upowerd"),
...
}
This is to avoid this denial:
type=SYSCALL msg=audit(1679948376.046:1319): arch=c000003e syscall=262
success=yes exit=0 a0=ffffffffffffff9c a1=c0001e47b0 a2=c0001246b8 a3=0
items=0 ppid=1 pid=40320 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snapd"
exe="/usr/libexec/snapd/snapd" subj=system_u:system_r:snappy_t:s0
key=(null)
type=AVC msg=audit(1679948376.046:1319): avc: denied { getattr } for
pid=40320 comm="snapd" path="/usr/libexec/upowerd" dev="sda2"
ino=2180887 scontext=system_u:system_r:snappy_t:s0
tcontext=system_u:object_r:devicekit_power_exec_t:s0 tclass=file
permissive=1
