Red Hat- and Debian- derived distributions support SELinux, and so their
sudo packages are built with SELinux support. However, other
distributions (notably Arch) build sudo without SELinux. Such sudo
builds will fail to parse the `ROLE=unconfined_r TYPE=unconfined_t`
string added in 0fac1aa45c. They *can*
parse `role=unconfined_r, type=unconfined_t` in `Defaults`, but that
causes problems on some Fedora 33 systems if SELinux is turned off and
the root account is locked.
To solve both of these problems at once, we install a different
`/etc/sudoers.d/qubes` file depending on the distribution. As a
heuristic, we use the presents of `/etc/redhat-release` or
`/etc/debian_version`. If either is present, sudo probably supports
SELinux, and we should include the corresponding entries. If both are
missing, then we shouldn’t risk it. The `qubes.sudoers` file in the git
repository includes the full file (with SELinux); we use `sed` to strip
the SELinux portion when needed.
qubes-core-agent-networking package brings in new systemd units, which
needs to be enabled. Standard %systemd_post macro handles it only on
initial installation, but not on update. The function that handle
updates is in %post of qubes-core-agent-systemd package. To avoid
duplication, simply enforce proper installation order, instead of
modifying %post of qubes-core-agent-networking package.
OrderWithRequires influences only ordering, but does not introduce
actual dependency, so it's still possible to not install
qubes-core-agent-networking package.
Fixes 0e0c229 "rpm: enable qubes-network-uplink.service on install"
By settinf Defaults role/type parameters, sudo starts asking for
password when called as root. It isn't clear why this happens, but
rollback that change. Instead, set ROLE/TYPE just for the rule for the
'qubes' group, which already has NOPASSWD option.
Fixes 3bcc1c3 "“sudo” must remove SELinux restrictions"
The setup-ip script requires extra parameters (action and interface) not
only env variables. Since NetworkManager service is already ordered
after qubes-network-uplink.service, the setup-ip already did its job at
this time - remove the call instead of fixing it.
* origin/pr/267:
fix for ArchLinux: notify dom0 about installed updates The launch of the qubes-update-check service failed on ArchLinux, because the qubes-rpc uses the `service` command which isn't available for this OS.
fix archlinux detection of available upgrades note: checkupdates return 2 when no updates are available (source: man page and source code)
upgrades-installed-check requires pacman-contrib for checkupdates
The network-uplink-wait.sh script may be called before xen-netfront
module is even loaded (by udev). In that case, `get_qubes_managed_iface`
will fail to get the interface name and the wait will be skipped.
Fix this by loading xen-netfront module explicitly (do not try to
synchronize with udev, which is tricky not knowing the device
name).
* origin/pr/268:
Don’t rely on an arbitrary length limit
Don’t assume dom0 will never have a network connection
Add conntrack-tools dependency to qubes-core-agent-networking
Keep shellcheck from complaining
Stop disabling checksum offload
Remove spurious line continuation; add quotes.
vif-route-qubes: Check that the -e flag is set
Purge stale connection tracking entries
Otherwise, if “user” has the SELinux user “staff_u”, the user will
typically need to write “sudo -r unconfined_r -t unconfined_t”, which is
annoying. If SELinux is disabled, these fields are ignored.
Newer versions of qubes-dom0-update will spawn
qubes-download-dom0-updates.sh in an xterm if GUI mode is enabled.
Therefore, we don’t need to spawn our own progress bar.