Re: glibc in master is incompatible with systemd-nspawn

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> On 08/11/2019 11:45, Florian Weimer wrote:
>> * Dmitry V. Levin:
>> 
>>> On Fri, Nov 08, 2019 at 12:08:29PM +0100, Florian Weimer wrote:
>>>> systemd-nspawn (at least the Fedora version) applies a system call
>>>> filter which causes system calls to fail with EPERM instead of ENOSYS.
>>>> This breaks our fallback handling.  This problem has existed for a long
>>>> time, but it has become more prevalent with the recent time64 changes.
>>>
>>> Yes, this has been a long time issue for strace test suite, too.
>> 
>> And based on the systemd-nspawn manual page, there is no way to turn
>> this off:
>> 
>> “
>> Note that systemd-nspawn always implements a system call whitelist (as
>> opposed to a blacklist), and this command line option hence adds or
>> removes entries from the default whitelist, depending on the "~"
>> prefix.
>> ”

> Also, returning EPERM in such case might be confusing in some specific
> syscalls that does return EPERM as a valid error (renameat2 for instance).

I agree.

> Since when systemd-nspawn has this behaviour? What was the rationale to
> use EPERM instead of ENOSYS? IMHO ENOSYS it the expected error in this
> case, since filtering is essentially blocking the syscall usage altogether.

I don't have any good answers to these questions.  There is some
additional discussion on these bugs:

  <https://bugzilla.redhat.com/show_bug.cgi?id=1769299>
  <https://bugzilla.redhat.com/show_bug.cgi?id=1770154>

Thanks,
Florian