<table><tr><td style="">davidk added a comment.<br />Restricted Application edited subscribers, added: kde-frameworks-devel; removed: Frameworks.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8532">View Revision</a></tr></table><br /><div><div><p>I was asked in private about the current state of libseccomp integration and why there was no progress in a long time.<br />
The current state is, that I have implemented seccomp support in kfilemetadata using this API:</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">bool setProcessReadOnly(uint32_t defaultAction, std::vector<SeccompFilter> addionalWhitelist)</pre></div>

<p>But there are two blockers, related to external plugins:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">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.</li>
<li class="remarkup-list-item">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.</li>
</ul>

<p>So, if anyone is willing to continue this work, I would be happy to share my current state.<br />
Otherwise, if everyone agrees that we don't care about external plugins (users of external plugins can disable Seccomp support with an environment variable), I can finish the patches.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R293 Baloo</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8532">https://phabricator.kde.org/D8532</a></div></div><br /><div><strong>To: </strong>davidk, apol, ossi<br /><strong>Cc: </strong>kde-frameworks-devel, michaelh, Baloo, detlefe, ngraham, nicolasfella, ashaposhnikov, astippich, spoorun, bruns, abrahams, Frameworks<br /></div>