Make qubes.NotifyTools reuse logic of qubes.FeaturesRequest, then move
actual request processing to 'features-request' event handler. At the
same time implement handling 'qrexec' and 'gui' features request -
allowing to set template features when wasn't already there.
Behavior change: template is no longer allowed to change feature value
(regardless of being True or False). This means the user will always be
able to override what template have set.
And place them in /qubes-service/ QubesDB directory. This allows
extensions to easily store some data not exposed to VM, but also have
control what VM will see. And at the same time, it make it compatible
with existing services framework
QubesOS/qubes-issues#1637
...in core-mgmt-client repository. qubesd isn't the right place to start
GUI applications, which will be even more important when GUI domain will
be something different than Dom0.
QubesOS/qubes-issues#833
This is migration of core2 commits:
commit d0ba43f253
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Mon Jun 6 02:21:08 2016 +0200
core: start guid as normal user even when VM started by root
Another attempt to avoid permissions-related problems...
QubesOS/qubes-issues#1768
commit 89d002a031
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Mon Jun 6 02:19:51 2016 +0200
core: use runuser instead of sudo for switching root->user
There are problems with using sudo in early system startup
(systemd-logind not running yet, pam_systemd timeouts). Since we don't
need full session here, runuser is good enough (even better: faster).
commit 2265fd3d52
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Sat Jun 4 17:42:24 2016 +0200
core: start qubesdb as normal user, even when VM is started by root
On VM start, old qubesdb-daemon is terminated (if still running). In
practice it happen only at VM startart (shutdown and quickly start
again). But in that case, if the VM was started by root, such operation
would fail.
So when VM is started by root, make sure that qubesdb-daemon will be
running as normal user (the first user in group 'qubes' - there should
be only one).
FixesQubesOS/qubes-issues#1745
Commit from core2:
commit 94d52a13e7
core: adjust guid parameters when running on KDE5
On KDE5 native decoration plugin is used and requires special properties
set (instead of `_QUBES_VMNAME` etc).
Special care needs to be taken when detecting environment, because
environment variables aren't good enough - this script may be running
with cleared environment (through sudo, or from systemd). So check
properties of X11 root window.
QubesOS/qubes-issues#1784
Instead of old per-VM flag 'pci_strictreset', now implement this as
per-device flag using features. To not fail on particular device
assignment set 'pci-no-strict-reset/DEVICE-BDF' to True. For
example 'pci-no-strict-reset/00:1b.0'.
QubesOS/qubes-issues#2257
Implement required event handlers according to documentation in
qubes.devices.
A modification of qubes.devices.DeviceInfo is needed to allow dynamic,
read-only properties.
QubesOS/qubes-issues#2257
When properly set, applications will have a chance to automatically
detect HiDPI and act accordingly. This is the case for Fedora 23
template and GNOME apps (maybe even all built on top of GTK).
But for privacy reasons, don't provide real values, only some
approximate one. Give enough information to distinguish DPI above 150,
200 and 300. This is some compromise between privacy and HiDPI support.
QubesOS/qubes-issues#1951
This commit is migrated from gui-daemon repository
(dec462795d14a336bf27cc46948bbd592c307401).
This allows the user to start VM based on "old" system (from R3.x) in
R4.0. For example after restoring from backup, or migration. This also
makes upgrade instruction much easier - no need complex recovery
instruction if one upgrade dom0 before upgrading all the templates.
QubesOS/qubes-issues#1812
