mgallien added a comment.
In D8532#289500 <https://phabricator.kde.org/D8532#289500>, @davidk wrote: > 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. > > So, if anyone is willing to continue this work, I would be happy to share my current state. 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. Sorry for my late reply The external extractors tests of KFileMetaData have always failed and nobody ever fixed them. This makes me think that they are not really maintained. Is there any use of them apart from the unit tests ? REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi, #frameworks, smithjd, bruns Cc: mgallien, kde-frameworks-devel, michaelh, #baloo, detlefe, ngraham, nicolasfella, ashaposhnikov, astippich, spoorun, bruns, abrahams
