[systemd-devel] How to disable seccomp in systemd-nspawn?

[Steve Dodd]

On Sun, 16 Aug 2020 at 14:54, Lennart Poettering <lennart at poettering.net>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200816/bfcbc616/attachment.htm>