interfaces: deny connected x11 plugs access to ICE
The ICE protocol allows the application to tell the session manager how
to restart an application from previously saved state, along with the
entire command line to execute. This can be used to craft a sandbox
escape, assuming a compatible session manager is used.
Merge pull request #9489 from anonymouse64/feature/snapd-shutdown-maintenance-json
daemon,client: write and read a maintenance.json file for when snapd is shut down
This is needed for more robustness in the very racy situation of trying to temporarily auto-refreshes for console-conf to run on first-boot, as we may come into the game when snapd is already down, and want to still display a nice message to the user rather than just "error: connection refused" because snapd is not responding to requests.
As such, we write a maintenance.json file when shutting down with details of why snapd is shutting down (i.e. just to restart itself or to wait for a full system reboot), and then check for this file from the client so we can know when this situation happened.
Note that currently, we just set the Maintenance on the client and move on with the request, because this is the least intrusive way to make this change, but ideally I think we should just skip the request entirely if we know for sure that snapd is shut down and won't respond anytime soon (i.e. for a reboot) but this is a bigger change and probably requires adjustments various other places too, so I opted for the safer, less intrusive change here.
tests/nested/core20/kernel-reseal: use the repacked test kernel
We cannot use the pc-kernel directly from the store as it may have a version of
snap-bootstrap that will be unable to unseal the keys and unlock the encrypted
volumes. Instead, use the version that kernel snap that was repacked with the
version of snap-boostrap from the current source tree.
Signed-off-by: Maciej Borzecki <email address hidden>
Merge pull request #9550 from anonymouse64/bugfix/mockdisk-verifies-consistency
osutil/disks/mockdisk: panic if same mountpoint shows up again with diff opts
We should panic if we are passed a mapping that has the same mountpoint with
different options show up twice, as this is an inconsistent world-view, as one
mountpoint can only have one option set on it. The reason we have this option as
the input and not as a property of the disk itself is so that we can verify the
input, as whether or not to expect a decrypted device is a thing we need to
test, but it does have the unfortunate side effect where you can create
situations like this.
