Avoid race conditions with services ordered shortly after qrexec start.
Make systemd know when qrexec-agent is really ready to serve.
FixesQubesOS/qubes-issues#3985
* origin/pr/141:
is_protected_file: if no config dir is present, assume the file is _not_ protected
/rw/config
Fix logic bug.
Allow per-VM protected file list
See
https://github.com/QubesOS/qubes-core-agent-linux/pull/146#discussion_r238080117
for details; but tl;dr:
* Journal size is 64M
* Inode table is 256 bytes * 643376 inodes allocated = ~157M
* Reserved GDT blocks take up 1024 blocks * 4096 byte block size = 4M
* Fixed-size parts of the filesystem probably take up another MB or
two
These actually adds up to more than the 222M number used in this
commit. But it seems _about_ right, so just Ship It(tm).
This reverts commit 8000e76d43, because
as @marmarek pointed out, the original was correct and I totally
misread. The check in question is checking whether to _abort_, not
whether to continue. So we want to check if the block device size is
_less_ than the filesystem + margin, not more.
ReopensQubesOS/qubes-issues#4553
qubes-core-agent depends on -qrexec, there is no need for the opposite
dependency. In fact one of the reasons for the package split was to
allow installing just -qrexec package.
Base qubes-core-agent package have common files used by various
subpackages. It is important to update them at the same time, otherwise
for example python stubs in /usr/bin/* (like qubes-firewall) will not
match actual python modules.
FixesQubesOS/qubes-issues#4499
* advertise-services:
archlinux: no longer need to mangle shebang for python scripts
Make shebang explicit /usr/bin/python2 where it's still there
Tell dom0 that VM is running Linux
Both Archlinux and Fedora 29 have guidelines to point explicitly at
/usr/bin/python2 where it expect python2.
Also, do not use env.
FixesQubesOS/qubes-issues#4027
* origin/pr/139:
Remove qubes-core-agent Debian dependency on xserver Mark xserver, xinit and x11-xserver-utils as Recommends
FixesQubesOS/qubes-issues#4202
In rare cases when vif-route-qubes is called simultaneously with some
other iptables-restore instance, it fails because of missing --wait (and
recent iptables-restore defaults to aborting instead of waiting
for lock). That other call may be from qubes-firewall or user script.
Related to QubesOS/qubes-issues#3665
It may be useful to create AppVM-specific menu entries in AppVM itself.
It may be an application installed there (in /usr/local, or using snap
QubesOS/qubes-issues#2766), but it may be also some user custom
shortcut.
To support this, dom0 will accept menu entries also from
TemplateBasedVMs. But to avoid duplicates, qubes.GetAppmenus service
should send only menu entries actually stored in that VM, not inherited
from its template. To distingush them, first check what type of
persistence this VM has (from qubesdb-read /qubes-vm-persistence). If
it's rw-only, send only entries stored on /rw.
To make it more robust, use $XDG_DATA_DIRS and $XDG_DATA_HOME to
discover directories, instead of looking only for
/usr/{,local/}share/applications. This makes snap and flatpak handled
for free.
FixesQubesOS/qubes-issues#4152
Previously, bind-dirs.sh had a bunch of `true comment goes here` style debug messages (no-ops). Presumably this was done because these messages are intended as debug messages and would only be displayed when calling bind-dirs.sh with xtrace enabled. However, this includes some fatal errors, which are necessary to debug why bind-dirs.sh is ostensibly not working. For example, I tried to mount /var/lib/docker, didn't realize it did not exist (as an empty directory) in my base template, and there was no journalctl output at all. After this change, journalctl will contain the (very helpful) error message.
