-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[v1.2 regression] SCMP_ACT_NOTIFY
rule for fcntl
causes runc to hang, before connecting to the seccomp listener agent
#4328
Comments
Looks like seccomping Minimal repro:
--- config.json.OLD 2024-06-28 14:27:41.625930763 +0900
+++ config.json 2024-06-28 14:28:02.228529889 +0900
@@ -173,6 +173,23 @@
"/proc/irq",
"/proc/sys",
"/proc/sysrq-trigger"
- ]
+ ],
+ "seccomp": {
+ "defaultAction": "SCMP_ACT_ALLOW",
+ "architectures": [
+ "SCMP_ARCH_X86_64",
+ "SCMP_ARCH_X86",
+ "SCMP_ARCH_X32"
+ ],
+ "listenerPath": "/run/user/1001/bypass4netns.sock",
+ "syscalls": [
+ {
+ "names": [
+ "fcntl"
+ ],
+ "action": "SCMP_ACT_NOTIFY"
+ }
+ ]
+ }
}
}
|
nerdctl run --annotation nerdctl/bypass4netns=1
hangsnerdctl run --annotation nerdctl/bypass4netns=1
hangs (due to SCMP_ACT_NOTIFY
with fnctl
)
Regression in 20b95f2 Seems to be related to https://cs.opensource.google/go/go/+/refs/tags/go1.22.4:src/os/file_unix.go;l=113 |
This is borderline for me. Is it a regression? I mean, I feel like we should be allowed to change which syscalls we do after the seccomp policies are applied and before the container entrypoint exec. Especially since we are using go, that we don't have so much control on which syscalls are used. In fact, this is a great example, it is not documented that os.File uses fcntl and they can probably change it in different versions of go. So it's hard for us to make promises, IMHO, when using such a high-level language. Can't this be handled properly in the seccomp agent? I think it should be easy to handle if the agent does: (a) accept all the syscalls on fds it doesn't know about (those where created before the agent received the message on the unix socket, so those are runc fds), or (b) accept all the syscalls before the first exec. I think one of those should be possible (IMHO the latter is more robust, I'd go for that) @AkihiroSuda what do you think? |
cc @naoki9911 (maintainer of https://github.com/rootless-containers/bypass4netns)
How can the agent detect the first exec? |
@AkihiroSuda if you notify on the exec syscall, then you can see if exec was done or not and accept all before processing an exec, after the exec do whatever the agent wants to do. If you do not want to handle exec, then just accepting all on unknown fds will do the trick too for this issue. |
But I honestly don't think this is something we want to fix in runc. I'm okay if the PR to fix this is very small, but it seems like the agent should handle this better (also, maybe the agent doesn't work with youki or other runtimes until it has a more robust handling of this). In fact, looking at the golang code you shared (https://cs.opensource.google/go/go/+/refs/tags/go1.22.4:src/os/file_unix.go;l=113) if only the agent returns an error, instead of hanging the syscall forever, it might just work fine. If fcntl returns an error, the runtime doesn't abort it at all in that function. I do think a better handling in the agent as I proposed in the comments above is better, but even this small fix might just cut it for this case. |
I confirmed the issue. bypass4netns always allows With runc v 1.1.13, bypass4netns hooks
But with runc v1.2.0-rc.2, bypass4nets does not receive any notifications.
bypass4netns does not receive notify fd with runc v1.2.0-rc.2. "syscalls": [
{
"names": [
- "fcntl"
+ "connect"
],
"action": "SCMP_ACT_NOTIFY"
}
]
I think this issue occurs in the establishment of seccomp notification connection. |
nerdctl run --annotation nerdctl/bypass4netns=1
hangs (due to SCMP_ACT_NOTIFY
with fnctl
)SCMP_ACT_NOTIFY
rule for fcntl
causes runc to hang, before connecting to the seccomp listener agent
Thinking about it more, we can probably break other setups changing the syscalls we do at that point. I think it is unlikely we do, but we can check if it's easy to fix this. Wanna take a look and open a PR? (for the agent, though, I think the changes we talked about are the way to go anyways) |
nerdctl run --rm --annotation nerdctl/bypass4netns=1 alpine echo hi
works with runc v1.1.13, but hangs with runc v1.2.0-rc.2.Reproduction steps:
containerd-rootless-setuptool.sh install containerd-rootless-setuptool.sh install-bypass4netnsd nerdctl run --rm --annotation nerdctl/bypass4netns=1 alpine echo hi
The text was updated successfully, but these errors were encountered: