I just want to say that this isn’t actually correct. It does affect X, but in that case ctrl-c doesn’t terminate your session for some reason I don’t understand. alt-left/right still switch the VT, your input goes to the console underneath Shell, etc. It is always a very bad idea to change the keyboard mode underneath your graphical environment. The environment itself can’t really do anything sensible about that - it’s really a “don’t do that then” thing.
The script was buggy in that it did exactly that - that’s been fixed (by removing it completely since it wasn’t required with systemd, but it could have been fixed in another way). Still, it is a problem that it was being invoked by udev via snapd in the first place. It’s not expected that this will happen. Thanks for adding it to your backlog - I hope it is resolved sooner or later.
AIUI, while snapd may be able to do something different, it isn’t actually doing anything wrong since the action is supposed to be safe. There are many examples of udevadm trigger in postinst scripts in the Debian and Ubuntu archives for example, some with --subsystem-match, but certainly not all.
Again, we may be able to do something more targeted to the device(s) being connected by the interface, but the fact remains that upon device assignment we need the devices to be udev tagged immediately so that the snap can start using the device before rebooting, and the way to make that take effect is via some call to udevadm trigger. The tty susbsystem is one of the subsystems snappy is interested in connecting, so even if we use udevadm trigger in a more targetted fashion, it will necessarily need to call udevadm trigger --subsystem-match=tty or udevadm trigger /dev/tty... for some snaps.
All that said, note that the long term goal is to have AppArmor solely mediate devices via static rules for devices with dependable names (something we already do) and via inode tagging hotplug/hotunplug-able devices (future) and not using device cgroups at all (and therefore no need to call udevadm trigger in any fashion). While this work is currently on the roadmap, it is unscheduled (but there is actually some work being contributed to the AppArmor upstream project to support storing security labels in inodes that we may be able to build on).
