On Sa, 15.08.20 13:33, Steve Dodd (steved424@xxxxxxxxx) wrote: > On Fri, 26 Jun 2020 at 16:53, Lennart Poettering <lennart@xxxxxxxxxxxxxx> > wrote: > > > > We implement a system call allow list, i.e. everything that isn't > > > > explicitly allowed is denied. You can use --system-call-filter=openat2 > > > > to allow a specific syscall on top of our defaults, i.e. extend the > > > > allow list, or remove entries from it. > > > [..] > > > You might need a newer libseccomp so that the syscall is actually > > known by it. openat2 is a very recent syscall addition, and you need > > to update libseccomp in lockstep if you want it to grok it. > > > > 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.. Which error to return is a bit of a bikeshedding thing. We return EPERM because this is about sandboxing for us, i.e. access control. And we want to communicate that correctly to payloads, so we say so. ENOSYS would be something we'd return if we'd pretend that something isn't available even though it is. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel