Sigh. quazip changed the lib name, include locations, etc. from version 1.
Some distributions only have 0.9. Some only 1.x and so some packages break,
so they simply patch it when building the package.
Luckily, nothing we use from quazip is affected from an API perspective.
So detect if there is quazip1, then use pkg-config to link that, else do it like before.
Not entirely ideal, since we may want to search for 'cake', and look at
a preview for 'cake.txt' even if there is no 'cake' inside.
But this will do for now
Switch to QCoreApplication, since the ipc worker is not a GUI application.
We can also remove some vows this ways. Furthermore, disable connect() syscall
explicitly.
While f67a37bc21 indicated the last remaining code could stay,
it can't because there is a launch failure of SandboxedProcessor.
This has been revealed by the changes of the previous commit,
aa03d0a4920e.
Hence, the GUI will be untouched by exile. We only sandbox
the preview generation and the indexing trough IPC.
There was an off-by-one, the SandboxedProcessor was only passed
'process', not the path to the file.
No processor was found for 'process', thus 'nothingProcessor' was
returned. Therefore, we never sandboxed (because we never had
to process anything).
The sandboxing would have failed though, because we need to launch
QCoreApplication, not QApplication.
The CLI was never affected.
It was possible the text was getting too big. The GUI
was lagging for previews of some text files. The first
assumption was that we would only have a couple of hits,
which is unreasonable for large .txt files and common
words.
We only ever see a handful of previews, it makes no sense
to get all snippets. So just allow 7 snippets, that's it.
Also, just cut after 1000 chars no matter what.
This prevents 'spam'. User may have scrolled 10 pages forward, while
we are still generating old pages. Then the user wonders why
they arrive so late.
So disable switching pages while the generation is still running
It is unlikely that a user will have to quickly go through search
results like that.
Qt is usually built with Accessibility and D-Bus. If D-Bus
connections work, a bypass should be considered trivial.
If we block D-Bus, we experience quite some slowdowns in
certain contexts. That's because Qt makes D-Bus connections
for accessibility features etc. They appear to run into timeouts,
but this slows down things. Sandboxing also makes things
like showing (native) file picker dialogs harder.
Sandboxing efforts will focus on the critical paths such as
the existing Indexer sandbox and the to be implemented sandboxing
for preview generation.
We keep no_new_privs for now as chances are that this shouldn't hurt.
The indexer is quite slow with unshared network namespaces. It appears something in
Qt needs it as IPC or whatever. Seeing also dbus-related errors:
Issue: #33
So disable it for now.
SandboxedProcessor is not launched via IPCServer at this point.
The vow set is already very big and SandboxedProcessor
would require exec too.
So use exile default policy and add some path permisisons.
Once SandboxedProcessor is handled by IPC and preview generation
is also exiled separately, it has to be reevaluated whether
it makes sense for vows to return.
avoids waiting in the gui thread. does not try to cancel
the QFuture that actually cannot be cancelled anyway.
sidesteps a strange bug which rethrows already caught exception.
