This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc in master is incompatible with systemd-nspawn
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.
> ”
No only for time64, but also for:
- mutex priority on some specific architectures (where either
CONFIG_HAVE_FUTEX_CMPXCHG is not enabled or if
futex_atomic_cmpxchg_inatomic fails at runtime as for some
specific architectures). However I assume futex is unlikely
to be on a filter list.
- nscd inotify support.
- preadv/pwritev/pselect on old microblaze kernels (in the other hand
the fallback are sub-optimal and racy).
- preadv2/pwritev2 with default 0 zero flag (which issues readv
or preadv).
- statfs/statx on some kernels.
Also, returning EPERM in such case might be confusing in some specific
syscalls that does return EPERM as a valid error (renameat2 for instance).
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.