Add support for mounting Unix sockets #235
Comments
|
I think @prattmic was looking into this recently. |
|
Relaxing this restriction is something that we've considered recently, at least for connecting to existing UDS (as opposed to binding new sockets). Would only being able to connect work for your use-case? Also note that it wouldn't be possible to send in-sandbox file descriptors over such a UDS to a process outside the sandbox, though I doubt you are trying to do that. |
|
I think that @jmillikin-stripe may not be near a laptop this week, so I'll jump in here and expand a bit: @jmillikin-stripe, please keep me honest! I'm pretty sure that we'd only be using the "connect to existing UDS" features, and we're not interested in passing file descriptors over it. The main use-case here is being able to proxy and filter traffic leaving a container in a useful manner; one thing that we've done with regular Docker is to run the container with |
|
Thanks for the details, I think that is a very reasonable use case. It will need a bit more investigation, but I think it is something we should be able to allow, especially if it is something that one of you want to look into hooking up. We do also have all the pieces to allow a custom network gofer (netgofer), but no API for it at the moment. And for this kind of fairly simple use case that would likely be overkill vs a simple UDS. |
prattmic
added
area: filesystem
I'm interested in looking into this, but I'll admit to being unfamiliar with gVisor's codebase. I found this chunk of code, which does not check for |
|
I'm happy to help figure out our codebase. :) BTW, we've just recently set up a Gitter channel if you want to join for more real-time questions. Connecting to a socket generally goes through the The good news is that the sentry (sandbox kernel) side already supports connecting to UDS through a gofer. It's just not supported by the gofer used in runsc. In the sentry both the fs and networking paths are fairly complicated and UDS combines both, so for posterity, here is the flow of connecting to a gofer-backed UDS: linux.Connect ( I don't think you should need to change any of the sentry code. On the gofer side, we'll call p9.File.Connect, which is where we need an implementation. We have pretty extensive UDS tests in our syscall tests. I'll have to think about the best way to hook up these gofer-backed sockets to those tests. Hopefully this should help you get a prototype working, and we can see where to go from there (should this be behind a flag, etc). [1] N.B. Tlconnect is a custom extension we've added to 9p. It's not standard: https://github.com/google/gvisor/blob/master/pkg/p9/version.go#L126 |
Updates #235 PiperOrigin-RevId: 271223983
Updates #235 PiperOrigin-RevId: 271475319
|
Note that this feature still has some issues:
I'll be sending out fixes for these (and more complete tests) soon. |
prattmic
changed the title
fsgofer.attachPoint.Attach has a bunch of funky special logic to create a RW file or connect a socket rather than creating a standard control file like localFile.Walk. This is unecessary and error-prone, as the attach point still has to go through Open or Connect which will properly convert the control file to something usable. As such, switch the logic to be equivalent to a simple Walk. Updates #235 PiperOrigin-RevId: 274235091
This change fixes several issues with the fsgofer host UDS support. Notably, it adds support for SOCK_SEQPACKET and SOCK_DGRAM sockets [1]. It also fixes unsafe use of unet.Socket, which could cause a panic if Socket.FD is called when err != nil, and calls to Socket.FD with nothing to prevent the garbage collector from destroying and closing the socket. A set of tests is added to exercise host UDS access. This required extracting most of the syscall test runner into a library that can be used by custom tests. Updates #235 Updates #1003 [1] N.B. SOCK_DGRAM sockets are likely not particularly useful, as a server can only reply to a client that binds first. We don't allow bind, so these are unlikely to be used. PiperOrigin-RevId: 272500970
fsgofer.attachPoint.Attach has a bunch of funky special logic to create a RW file or connect a socket rather than creating a standard control file like localFile.Walk. This is unecessary and error-prone, as the attach point still has to go through Open or Connect which will properly convert the control file to something usable. As such, switch the logic to be equivalent to a simple Walk. Updates #235 PiperOrigin-RevId: 274827872
This change fixes several issues with the fsgofer host UDS support. Notably, it adds support for SOCK_SEQPACKET and SOCK_DGRAM sockets [1]. It also fixes unsafe use of unet.Socket, which could cause a panic if Socket.FD is called when err != nil, and calls to Socket.FD with nothing to prevent the garbage collector from destroying and closing the socket. A set of tests is added to exercise host UDS access. This required extracting most of the syscall test runner into a library that can be used by custom tests. Updates #235 Updates #1003 [1] N.B. SOCK_DGRAM sockets are likely not particularly useful, as a server can only reply to a client that binds first. We don't allow bind, so these are unlikely to be used. PiperOrigin-RevId: 275558502
We want to run a gVisor sandbox without network access (
--network=none), and implement restricted access to a few hardened upstreams by mounting in Unix sockets. This pattern works in Docker because the sockets and container exist in the same kernel, but gVisor's filesystem sidecar doesn't seem to support mounting Unix sockets.#33 (comment) suggests this was intentional, for security. Would it be possible to relax that restriction, either by default or with a CLI flag?
Alternatively, is there any recommended way to add a "network gopher" that could run outside the sandbox and proxy TCP traffic?
The text was updated successfully, but these errors were encountered: