@zygoon@carlschwan@kde@kde It's likely coming from some usage of libseccomp somewhere. This also afflicts the container stack and such, which is why RHEL 9 containers on RHEL 7 are not supported.
Container/sandbox runtimes using libseccomp need to explicitly always allow clone3() through, or otherwise it will not fail correctly on RHEL 7.
@Conan_Kudo@carlschwan@kde@kde yeah, I strongly suspect seccomp. I’m debugging this now and I will share updates when I get to the bottom of the problem.
@zygoon@carlschwan@kde@kde The clone3() call is done implicitly and automatically by glibc. It started with glibc 2.34. This is most likely a problem in the Ubuntu Core 22 runtime that KDE snaps are built on.
The fix is to patch out the logic that uses it for clone() in Ubuntu's glibc.
@zygoon@kde@kde because any reasonable implementation will treat EPERM from a process creation system call as a fatal error. If this is e.g., blocked through seccomp. ENOSYS is the correct error to return. It's just naive seccomp sandboxes that started this EPERM nonsense. So I'd rule that out first. Unless you're using something that requires specific capabilities such as creating a process with a specific PID. That can legitimately return EPERM.
Thanks for the insight. I was surprised by EPERM, would have expected ENOSYS as well.
Looks like EPERM is most likely coming out of unknow system call name being filtered-out by snap-seccomp compiler. I'll update snapd to 2.61.1 to avoid chasing fixed bugs and then see if there's something to improve in the compiler.