Switch from libseccomp to seccompiler #26
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
boustrophedon
force-pushed
the
use_seccompiler
branch
from
213c759
to
a369f99
Compare
|
@gotlougit @Kijewski Sorry for the random mention, would either of you like to test this branch with your own code before I merge into master? |
|
That's great! I was expecting an "Operation not permitted" error for opening files, and I got it, so it works for me. |
Using seccompiler has three main advantages: - The entire codebase is in Rust - We get musl support for free - You don't need to have libseccomp installed on the target machine The biggest disadvantage is that we lose support for various platforms that libseccomp supports but seccompiler doesn't. However, since seccompiler supports aarch64 and x86_64 and 99% of software that would benefit from using seccomp runs on those platforms, I think it's a worthwile tradeoff. The other disadvantage is that seccompiler is not quite as mature as libseccomp and doesn't support all the features libseccomp does. I'm not currently using those features, several of which are aimed at container runtimes, so I don't see an issue for now.
boustrophedon
force-pushed
the
use_seccompiler
branch
from
a369f99
to
256ade4
Compare
boustrophedon
force-pushed
the
use_seccompiler
branch
from
256ade4
to
72645d9
Compare
|
@gotlougit by the way, I'm not sure if this solves your original problem but I ended up having to add pipes to the ForkAndExec ruleset to get subprocesses working on musl. I'm not sure if this was what you needed it for or not but I thought I'd let you know. I'm going to merge this PR today and release 0.3 to crates.io |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using seccompiler has three main advantages:
The biggest disadvantage is that we lose support for various platforms
that libseccomp supports but seccompiler doesn't. However, since
seccompiler supports aarch64 and x86_64 and 99% of software that would
benefit from using seccomp runs on those platforms, I think it's a
worthwile tradeoff.
The other disadvantage is that seccompiler is not quite as mature as
libseccomp and doesn't support all the features libseccomp does. I'm not
currently using those features, several of which are aimed at container
runtimes, so I don't see an issue for now.