-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
As discussed during the OCI call while #1018 was merged, it was made clear that @crosbymichael doesn't like having to give a path to an actual unix socket with --console-socket
. The main argument is that it has a lot of issues with pathname restrictions golang/go#6895 and that it requires touching the filesystem.
So, here's a quick list of hacks I tried before #1018 was merged with --console-socket
:
-
Something like
--console-fdpath
which allows you to specify a path to a/proc/[pid]/fd/N
"symlink" and then open it and use it like a socket. This idea sounds okay, but it doesn't actually work (attempting to open it gives youEXIO
) -- because opening a sockfd is not allowed in the kernel. -
Same idea as above but with
socketpair(2)
. You get the same problem. -
Abstract sockets. This avoids a lot of the problems, however Go doesn't have any bindings for this notion -- so you have to write it in C. After doing that you quickly notice that now you have to co-ordinate in an even more magical way than pathname sockets -- because there's no discoverability.
So there are two solutions we can go with:
-
--console-name "some abstract magical name"
which then uses an abstract socket for communication. While it works, there's no nice way of making sure that the socket exists or that any of this is working properly. The benefit of this approach is thatbats
testing will still work. -
--console-fd N
which uses the already-set-up file descriptor N as the open sockfd. This requires that the parent ofrunc
have already set up everything -- which means that now you have to engineer your own console management system to even begin to userunc create
. Which I think is pretty silly. Also testing is harder. The benefit is that it's not as magical as abstract socket namespaces.
/cc @crosbymichael