diff options
author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2018-09-20 14:19:41 +0200 |
---|---|---|
committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2018-09-24 17:21:09 +0200 |
commit | 7e86bd73a47f2b8dd3d9a743e69fb0117f450ad8 (patch) | |
tree | 89033936668e8ca342b36c0ae2f59965cf01411d /docs | |
parent | seccomp: reduce logging about failure to add syscall to seccomp (diff) | |
download | systemd-7e86bd73a47f2b8dd3d9a743e69fb0117f450ad8.tar.xz systemd-7e86bd73a47f2b8dd3d9a743e69fb0117f450ad8.zip |
seccomp: tighten checking of seccomp filter creation
In seccomp code, the code is changed to propagate errors which are about
anything other than unknown/unimplemented syscalls. I *think* such errors
should not happen in normal usage, but so far we would summarilly ignore all
errors, so that part is uncertain. If it turns out that other errors occur and
should be ignored, this should be added later.
In nspawn, we would count the number of added filters, but didn't use this for
anything. Drop that part.
The comments suggested that seccomp_add_syscall_filter_item() returned negative
if the syscall is unknown, but this wasn't true: it returns 0.
The error at this point can only be if the syscall was known but couldn't be
added. If the error comes from our internal whitelist in nspawn, treat this as
error, because it means that our internal table is wrong. If the error comes
from user arguments, warn and ignore. (If some syscall is not known at current
architecture, it is still silently ignored.)
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions