<div dir="ltr"><div dir="ltr">On Fri, 26 Jun 2020 at 16:53, Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > We implement a system call allow list, i.e. everything that isn't<br>
> > explicitly allowed is denied. You can use --system-call-filter=openat2<br>
> > to allow a specific syscall on top of our defaults, i.e. extend the<br>
> > allow list, or remove entries from it.<br></blockquote><div>[..] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You might need a newer libseccomp so that the syscall is actually<br>
known by it. openat2 is a very recent syscall addition, and you need<br>
to update libseccomp in lockstep if you want it to grok it.<br></blockquote><div><br></div><div>I've just been bitten by this - last time I looked into a similar problem, it seemed the calling code was confused by getting EPERM instead of ENOSYS. Could we distinguish between these two cases and generate the right error code? It would save a lot of aggro when working with containers..</div><div><br></div><div>S.</div></div></div>