I was asked in private about the current state of libseccomp integration and why there was no progress in a long time.
The current state is, that I have implemented seccomp support in kfilemetadata using this API:

bool setProcessReadOnly(uint32_t defaultAction, std::vector<SeccompFilter> addionalWhitelist)

But there are two blockers, related to external plugins:

• External plugins based on interpreters like python/lua/perl etc. need a huge whitelist. This is problematic as I want to keep the list of allowed syscalls as small as possible (the list would be huge). Additionally, it would be difficult to get a list of all needed syscalls. Thus, we would break many external plugins.
• Baloo is basically unmaintained. Thus, if something breaks, fixing it should be as easy as possible. But what if QT requires a new syscall and thus, the tests (and deployments) are failing? We need a way to know which syscall failed. This works for kfilemetadata plugins, but not for external plugins (because they are separate processes). The only way I can image, would be running the whole test with strace.

In D8532#215476, @michaelh wrote:

I don't know Seccomp. But as far as I understood this, the same concers apply to the baloo_file_temp_extractor baloo-widgets is using. Naivly I suggest to implement this KFileMetadata because both executables are using it. I don't know if that is possible or reasonable though.

I think Seccomp would be usefull in the baloo_file_temp_extractor too. What API would you suggest? I think on something like

KFileMetaData::setProcessReadOnly(KFileMetaData::SeccompAction action, QList<KFileMetaData::SeccompFilter> addionalWhitelist)

Sorry for the late reply and the slow process in general. Reallife keeps me busy...

In D8532#198408, @detlefe wrote:

A whitelist, even if it is broad, would be desirable to reduce the attack surface of the kernel, and is also the way it has been done for Gnome Tracker. But the concerns about maintenance remain, it probably should be tested regularly. Are there ways this can be automated?

If we want to test this, we would need a directory with files for each extractor (kfilemetadata includes such files for its autotests). Then, we should configure seccomp to kill the process if it calls a prohibited syscall. The test should then index all files in the directory. Unfortunately we can't test some things, e.g. the dbus integration and communication with baloo_file. This would need a test which starts the whole extractor as a child process. But i'm not sure if thats feasible. What do you think?

In case the decision goes in favor of the blacklist, would it be possible to add ptrace, process_vm_readv, process_vm_writev?

That's possible of course.

So shall this go into master or 17.12? It needs the change in kdepim-runtime to improve things.

Improve uservisible message.

The change improves the current state in case the user doesn't grant the access scopes. Only if the user presses the cancel button, the change in libkgapi is needed. So I think it makes sense in 17.12.

kdepim-runtime RR: D10222

Shall I push it to 17.12?

Push to 17.12?

So, are there any more opinions on the whitelist vs. blacklist topic?
Personally I still prefer the blacklist as I fear regressions in the future, especially because baloo is unmaintained.

Update TODO items.

Thanks for your review.

Fix version.

@cgiboudeaux is it ready to go now?

Unfortunately i can't reproduce the crash (with QT 5.10.0).

I'm fine with putting a QStringLiteral version into 17.12.

Fix most issues.

Fix style and constify

Remove question in commit message

In D9843#190037, @mlaurent wrote:

It's good if it logs now.
But where do you find info about new url ?

In D8532#175079, @ossi wrote:

you *really* should use a whitelist. it's ok if that breaks some 3rdparty extractor; you'll get a bug report which you can properly evaluate.
you could go totally overboard and assign fine-grained syscall capabilities to individual extractors, but i can't really think of legitimate reasons why that would be necessary in this context.

Fix remaining problems

Just adding my 2 cent: I think the filter should work fine, as SCMP_SYS is explicit available to support different platforms. If the syscall isn't available, it uses negative pseudo syscall numbers to ignore those syscalls.

In D9673#186294, @bshah wrote:

Uh, sorry I forgot to mention in orignial PR: but https://phabricator.kde.org/D9225

In D8756#186280, @davidk wrote:

I'm not sure what happens here as well. I guess that arm64 doesn't implement many syscalls. I will prepare a patch to exclude those syscalls if they're not available.

In D8756#176550, @bshah wrote:

Hello,

It seems this commit doesn't seem to build on arm64 properly: https://build.neon.kde.org/job/xenial_unstable_plasma_kscreenlocker_bin_arm64/1/console

I don't exactly understand what's going on.

Thank you, missed this when renaming the docs.

Fix variable names

Remove apparently unneeded version check

Improve commit message

Thanks for the git hint and the revew.
Then we should remove this code too.

In D8330#165813, @ngraham wrote:

@davidk, I think you have commit rights; do you want to do the honors?

Fix commit message.

Adding some devs who worked on kfilemetadata in the past.

In D8330#156180, @mgallien wrote:

I am not sure about the qWarning.
I would prefer another opinion on that.

When having many devices, the list quickly becomes longer than the available space and you need to scroll. Which is difficult, because you can't use the scrollwheel for that on most of the applet because of the sliders.

That's an issue in systray and not in plasma-pa, you can always use it outside of systray to have bigger popup.

I've tried disabling the wheel scrolling on sliders (because you can't disable it with QtQuickControls) with various hacks, but I failed. There was a patch to Qt to make it configurable, but it was rejected.

In D4324#80955, @broulik wrote:

I think this is just working around the fact that a KCM has no way of postponing the closing/deletion of the dialog when OK is clicked. We have the issue of OK not saving settings properly in various other places that use jobs, too.

This needs more changes, will upload again if everything works.

Fix method name

Move the file instead of copying it

Thanks for pointing this out, pushed in a separate commit.

Sorry for the noise, I have some problems with phabricator.