-
Notifications
You must be signed in to change notification settings - Fork 549
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
Incorrect default errnoRet ? #1122
Comments
The default is EPERM because that is the historical default and we need to maintain backwards compatibility with older configurations. However, in runc we have a somewhat complicated mechanism to make sure we return ENOSYS for syscalls that are above the highest-specified syscall number in the profile -- this means that assuming you are using a new enough version of runc (1.0.0-rc95 or later from memory) you shouldn't be hitting this issue. (The reason why we have this complicated setup rather than just returning ENOSYS is because existing profiles assume that missing syscalls will return EPERM. Every other solution I could think of was either too brittle due to libseccomp missing the features we need -- even now runc does some monkey-patching of the libseccomp-generated BPF.) |
eesh The tldr of all of this is a runc container is unable to execute x86 32-bit binaries. ioctl's for statx fail with EPERM.
Honestly, i'm just looking for what needs to happen to fix the issue and am in over my head at this point without learning all of the internals of runc. |
Oh.. as for runc:
|
does it work if you force |
@giuseppe , @cyphar , so what? The specification still twice mentions EPERM as default error code here: https://github.com/opencontainers/runtime-spec/blob/46369fd11df9103237e0f862499e9e57fe1f4e6e/config-linux.md?plain=1 (Ctrl-F reveals two EPERM mentions in the text). Please do what richfelker suggested in #1087 (comment) : "Why can't the spec just be fixed to specify what runc is doing to fix the problem?" |
we allow to override the default errno now. I think this is a solved problem |
It appears per concourse/concourse#7471 and @fweimer-rh that the wrong errnoRet is chosen in the golang runtime-spec?
The default is EPERM, and @fweimer-rh is indicating it should be ENOSYS instead?
On Fedora 34 systems, this is causing 32-bit code to fail to run within 64-bit x86_64 containers.
The text was updated successfully, but these errors were encountered: