Such that the snap application which apparently has matching devices will
execute with proper tracking enabled.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
It is possible that the snap process has not been moved to the snap specific
tracking cgroup. In this case, setting up a device filtering on the group can
negatively affect whatever group the process is part of. Try to catch test
scenarios when thiss happens, so that we may reach a reasonable solution.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
For some reason, the old code was causing snapd to hang when asked to
terminate if there were still some clients connected: the connection
would not move to the "idle" state.
This was found while investigating LP#1946656, and as a matter of facts
it fixes it. While debugging, an inspection of snapd threads while in
hanging state revealed that one thread was stuck in
daemon.(*ucrednetConn).Read
and it was verified that removing the Accept function completely would
resolve the issue (though also considerably changing snapd behaviour).
The problem with the old code does not lie in duplicating the file
descriptor (which is done by calling UnixConn.File()), but rather in the
apparently innocuous call to File.Fd(): as it can be seen by looking at
its source code[^note1], this function sets the file descriptor mode to
blocking, and this is what causes our connections to hang.
[^note1]: https://cs.opensource.google/go/go/+/refs/tags/go1.17.2:src/os/file_unix.go;l=81-88
Observed on an Impish s390x machine:
root@test-i:~# ls -lah /usr/lib/ld64.so.1
lrwxrwxrwx 1 root root 25 Sep 2 21:26 /usr/lib/ld64.so.1 -> s390x-linux-gnu/ld64.so.1
Which comes from the new libc6, and is different from what we expected on
previous releases, see for example Hirsute:
root@testing-h:~# ls -lah /usr/lib/ld64.so.1
lrwxrwxrwx 1 root root 26 Mar 31 2021 /usr/lib/ld64.so.1 -> s390x-linux-gnu/ld-2.33.so
The latter matched the existing rule, while the former does not. The new rule
allows both.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Merge pull request #10930 from anonymouse64/revert-10715-bump-secboot
Reverts #10715
Sadly the new version of secboot seems to auto-upgrade v1 keys to v2, which old recovery systems and even the currently published initrds/kernels do not understand so they fail to unlock the encrypted partitions in the initrd.
This PR includes #10929 which adds the following tests:
* test from stable snapd + stable kernel refreshing to snapd from the PR
* test from stable kernel + snapd from the PR
and for each variant then do something which triggers a reseal operation and a reboot to ensure that the new snapd will not break old recovery system kernels
When building on LP, the mock snap files generated with mksquashfs end up having
the same sha3-348 digest, despite forcing a 1s delay between consecutive snap
builds, what should have affected the internal file timestamps. As a workaround,
use a different content of mock files, such that the files must yield a
different digest.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Maciej Borzecki
Tao Wang
Alberto Mardegan
Ian Johnson
Samuele Pedroni
Michael Vogt