This is to allow permissions to be set on some devices where the user needs
less restrictive permissions. /etc/udev/rules.d/99-qubes-misc.rules changes
a few xen devices to allow the users in the qubes group access
Generate user-groups via -U instead of explicit via groupadd. This also
fix the problem that the tinyproxy group were not gererated as
"system"-group.
Also suppress unneeded output of the existence test.
Starting services in the postinst script doesn't make much sense since
the package is normally installed in the template. In addition the start
can fail when executed through a trigger.
/etc/iptables/rules.* are already part of the packet.
The removed code has never done something in debian (since
/etc/iptables/rules.* already exists).
This patch introduces two new qvm-services:
- disable-default-route
- disable-dns-server
Both disabled by default. You can enable any of them to not set default
route and/or DNS servers in the VM. Those settings have no effect on
NetVM, where such settings are controlled by NetworkManager.
This is based on patch sent by Joonas Lehtonen
<joonas.lehtonen@openmailbox.org>
https://groups.google.com/d/msgid/qubes-devel/54C7FB59.2020603%40openmailbox.org
Conflicts:
network/setup-ip
vm-init.d/qubes-core
vm-systemd/qubes-sysinit.sh
/proc is needed to link files opened with O_TMPFILE to the filesystem.
If not available, fallback to using permissions to block file access,
instead of failing the whole file copy.
This patch introduces two new qvm-services:
- set-default-route
- set-dns-server
Both enabled by default. You can disable any of them to not set default
route and/or DNS servers in the VM. Those settings have no effect on
NetVM, where such settings are controlled by NetworkManager.
This is based on patch sent by Joonas Lehtonen
<joonas.lehtonen@openmailbox.org>
https://groups.google.com/d/msgid/qubes-devel/54C39656.3090303%40openmailbox.org
Conflicts:
network/setup-ip
vm-init.d/qubes-core
vm-systemd/qubes-sysinit.sh
Otherwise, when the user moves directory, which is still in transfer,
somewhere else, it could allow malicious source domain to escape chroot
and place a file in arbitrary location.
It looks like bind mount is just enough - simple rename fails with
EXDEV, so tools are forced to perform copy+delete, which is enough to
keep unpacker process away from new file location.
One inconvenient detail is that we must clean the mount after transfer
finishes, so root perms cannot be dropped completely. We keep separate
process for only that reason.
Moved iptables configuration to /usr/lib/qubes/init
fc21 + debian + arch will place them in proper place on postinst
Fixes dedian bug of not having them in proper place
