Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

faccessat2 throws EPERM instead of ENOSYS #6562

Closed
agowa opened this issue Feb 17, 2021 · 2 comments
Closed

faccessat2 throws EPERM instead of ENOSYS #6562

agowa opened this issue Feb 17, 2021 · 2 comments

Comments

@agowa
Copy link

agowa commented Feb 17, 2021

Environment

Windows build number: `Microsoft Windows [Version 10.0.21313.1000]`
Your Distribution version: docker using wsl2
Whether the issue is on WSL 2 and/or WSL 1: WSL 2 (through docker)

Steps to reproduce

  1. docker run --network=host --rm -it archlinux/base:latest /bin/bash
  2. pacman -Syy
  3. pacman -S glibc runc To update glibc and runc individually.
  4. pacman -Syu Just a command that uses the affected (missing) syscall.

strace:

faccessat2(AT_FDCWD, "/var/lib/pacman/", F_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)

and if run using --privileged

faccessat2(AT_FDCWD, "/var/lib/pacman/", F_OK, AT_EACCESS) = -1 ENOSYS (Function not implemented)

WSL logs:

Expected behavior

The syscall should either be implemented (updating to kernel >5.8) or throw the "ENOSYS" instead of "EPERM".

Actual behavior

Linux 5.8 introduced a new syscall "faccessat2" which is required by current glibc and runc versions. Because of that ArchLinux docker containers fail to run on WSL2 right now with strange errors. Also the package manager pacman is suffering from this issue.

For the above mentioned example with pacman the output is:

error: failed to initialize alpm library
(could not find or read directory: /var/lib/pacman/)

Note: also whitelisting this syscall using --security-opt seccomp=test.json didn't work. As it still returns EPERM instead of ENOSYS...

Workarounds

  1. Running the docker container with --privileged works around this issue, as it returns the correct ENOSYS response.

Relates to

https://bugs.archlinux.org/index.php?do=details&task_id=69563

@DHowett
Copy link
Member

DHowett commented Feb 17, 2021

As I understand it, WSL 2 does not reimplement or interpose itself between the application and any system calls. Since it uses the actual Linux kernel, the response you get is in line with what you should get from 5.4 or 4.19 (depending on which you’re currently running.)

@therealkenc
Copy link
Collaborator

therealkenc commented Feb 17, 2021

Same behavior under docker on a Real Linux™ Ubuntu 20.10 box. The linked thread in the OP mostly speaks for itself.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants