On Sun, 16 Aug 2020 at 14:54, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
> 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.
I'm assuming we don't actually check what's available on the host kernel.. All the problems I've hit around this have been new syscalls which libc tests for by checking for ENOSYS - if it gets that, it falls back to a different implementation. If it gets EPERM, however, it just assumes the operation failed and returns to caller, which leaves poor users like me and the OP scratching their heads :)
A rule of thumb might be to return ENOSYS for anything libseccomp doesn't know about - is it possible to look things up that way around?
Another useful thing might be to allow whitelisting by syscall number - again don't know if seccomp allows this. Would allow easier work arounds in cases like this without having to go off and backport libseccomp...
Third thing on my wishlist might be a log entry for denied syscalls somewhere ..
S.
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
