-
Notifications
You must be signed in to change notification settings - Fork 150
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
Creating a sysbox container with systemd >= 247.2 may fail #273
Comments
@ctalledo Well, in any case before I reached out for GLibC part, I updated it all, so it definitely might be the case because systemd( Really confusing is why on casual |
Regarding faccessat2, I can find |
@ctalledo Should I mentioned earlier that I use userns to resolve the issue with CIFS, so my
But since I think you ran your tests without it, it probably does not matter much. |
I did a little bit of research. The syscall that brings up the issue came is implemented in kernel 3.8, to which I update(via Ubuntu HWE version) - okay. Turns out, Docker already has workaround for it and likely I have version installed which includes these half-year-ago fixes: moby/moby#41353 But then I looked up your documentation and it states that you do not allow I am really eager for this problem to get fixed tho. |
@ctalledo I made a simple PR, would you kindly test if it works? I think compatibility is a major issue unless you somehow embed libseccomp on the spot(about 2.5.0 is sufficient, this one is available on Focal). |
Thanks; yes will give this a shot later today. |
Hi @AlexTalker, I got a chance to look into this issue. I can confirm that adding the faccessat2() syscall to the Sysbox seccomp lib and sysbox-runc syscall list will fix the issue. I'll be creating a PR tomorrow, hopefully it will be committed by the weekend (after code-review). I also noticed that even with the fix, deploying a sysbox container using the To overcome this, I will create a Dockerfile for a nestybox/manjarolinux-systemd image that is essentially the same as the the nestybox/archlinux-systemd Dockerfile, except it inherits Using a local image based on this
|
The following PRs have the required fix: nestybox/sysbox-runc#36 And this additional PR has a couple of reference Dockerfiles to run manjaro linux inside sysbox containers: |
PRs have been merged, closing this issue. Please re-open if you see any problems. |
This problem was reported by @AlexTalker in a comment in issue #269. I am creating this dedicated issue to track it as it's a different problem than #269.
Basically, creating a sysbox container with the latest
manjarolinux/base
image fails:I dug a bit, and I can see the failure is due to the systemd instance inside the container getting an EPERM when executing a syscall:
This syscall is in fact the recently added
faccessat2()
system call in Linux.This syscall, like it's older sibling
faccessat()
checks a user's permissions on a given file but supports an extra flags parameter. Apparently recent versions of gcc are generating binaries with this syscall.It's unclear however why the syscall returns EPERM and whether this has anything to do with the fact that Sysbox uses rootless containers via the Linux user-namespace. Unfortunately the strace version I have did not decode the syscall parameters to give us a better clue.
The problem is not specific to Sysbox. I see the following recent mentions of it too:
https://serverfault.com/questions/1052963/pacman-doesnt-work-in-docker-image
https://bugzilla.redhat.com/show_bug.cgi?id=1869030
Per Alex's report in #269, this issue impacts containers with systemd versions > 247.2:
"So I pulled it, ran and it works too. I scratched my head a bit and found out that difference is down to minors - this image too has 247 Systemd but it's 247.2 and Manjaro is 247.6. So I ran pacman -Syu and it gave me 248, after which container does no longer starts"
We need to investigate further to see why the faccess2() syscall fails and how we can overcome this.
The text was updated successfully, but these errors were encountered: