netns : close all sockets at unshare ?
Hi,
I was looking at some cornercases and trying to figure out what happens if someone does:
1 - fd = socket(...)
2 - unshare(CLONE_NEWNET)
3 - bind(fd, ...) / listen(fd, ...)
There is here an interaction between two namespaces.
Trying to catch all these little tricky paths everywhere with the network namespace is painful, perhaps we should consider a more radical solution.
Shall we close all fd sockets when doing an unshare ? like a close-on-exec behavior ?
A message that is not in the archive (sent off-list or not yet received): 4702BBF4.60903-NmTC/[email protected]
Quoted 5 lines · Daniel Lezcano
Hi,
I was looking at some cornercases and trying to figure out what happens if someone does:
Quoted 7 lines
1 - fd = socket(...)
2 -unshare(CLONE_NEWNET)
3 -bind(fd, ...)/listen(fd, ...)There is here an interaction between two namespaces.
Trying to catch all these little tricky paths everywhere with the network namespace is painful, perhaps we should consider a more radical solution.
Huh?
socket() puts the namespace on struct sock.
bind/listen etc just look at that namespace.
Unless I'm blind it is simple and it works now.
Quoted 2 lines
Shall we close all fd sockets when doing an unshare ? like a close-on-exec behavior ?
I think adopting that policy would dramatically reduce the usefulness of network namespaces.
Making the mix and match cases gives the implementation much more flexibility and it doesn't appear that hard right now.
Eric
A message that is not in the archive (sent off-list or not yet received): m14ph9i1l3.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org
Quoted 15 lines · Eric W. Biederman
Quoted 5 lines · Daniel Lezcano
Hi,
I was looking at some cornercases and trying to figure out what happens if someone does:
Quoted 7 lines
1 - fd = socket(...)
2 -unshare(CLONE_NEWNET)
3 -bind(fd, ...)/listen(fd, ...)There is here an interaction between two namespaces.
Trying to catch all these little tricky paths everywhere with the network namespace is painful, perhaps we should consider a more radical solution.
Quoted 6 lines
Huh?
socket()puts the namespace on struct sock.
bind/listen etc just look at that namespace.Unless I'm blind it is simple and it works now.
Yes, it will work.
Do we want to be inside a network namespace and to use a socket belonging to another network namespace ? If yes, then my remark is irrelevant.
Quoted 8 lines
Quoted 2 lines
Shall we close all fd sockets when doing an unshare ? like a close-on-exec behavior ?
I think adopting that policy would dramatically reduce the usefulness of network namespaces.
Making the mix and match cases gives the implementation much more flexibility and it doesn't appear that hard right now.
I am curious, why such functionality is useful ?
A message that is not in the archive (sent off-list or not yet received): 47035591.4030300-NmTC/[email protected]
Quoted 5 lines · Daniel Lezcano
Yes, it will work.
Do we want to be inside a network namespace and to use a socket belonging to another network namespace ? If yes, then my remark is irrelevant.
Yes we do.
Quoted 10 lines
Quoted 8 lines
Quoted 2 lines
Shall we close all fd sockets when doing an unshare ? like a close-on-exec behavior ?
I think adopting that policy would dramatically reduce the usefulness of network namespaces.
Making the mix and match cases gives the implementation much more flexibility and it doesn't appear that hard right now.
I am curious, why such functionality is useful ?
There are several reasons. Partly it is the principle of building general purpose tools that can be used in a flexible way.
The biggest practical use I can see is that a control program outside of a network namespace can configure and setup someone else's network stack, perhaps preventing the need to enter someone else's container.
Another use is having a socket in an original network namespace for doing a stdin/stdout style connections.
The planetlab folks are actually actively using this functionality already, and there was a thread several months ago about how this functionality was important and how they were using it.
This also preserves normal unix file descriptor passing semantics.
A final reason for it is that it removes the need for a lot of brittle special cases when network namespaces are mixed in something other then a 1-1 correspondence with other namespaces. Like the one you were concerned with in unshare. Handling this case means everything just works.
So it may be a touch harder to implement but because we don't add special rules it is much easier to review.
Eric
A message that is not in the archive (sent off-list or not yet received): m1r6kccexw.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org
Quoted 33 lines · Eric W. Biederman
Quoted 4 lines · Daniel Lezcano
Yes, it will work.
Do we want to be inside a network namespace and to use a socket belonging to another network namespace ? If yes, then my remark is irrelevant.
Yes we do.
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
Shall we close all fd sockets when doing an unshare ? like a close-on-exec behavior ?
I think adopting that policy would dramatically reduce the usefulness of network namespaces.
Making the mix and match cases gives the implementation much more flexibility and it doesn't appear that hard right now.
I am curious, why such functionality is useful ?
There are several reasons. Partly it is the principle of building general purpose tools that can be used in a flexible way.
The biggest practical use I can see is that a control program outside of a network namespace can configure and setup someone else's network stack, perhaps preventing the need to enter someone else's container.
Another use is having a socket in an original network namespace for doing a stdin/stdout style connections.
The planetlab folks are actually actively using this functionality already, and there was a thread several months ago about how this functionality was important and how they were using it.
This also preserves normal unix file descriptor passing semantics.
Quoted 8 lines
A final reason for it is that it removes the need for a lot of brittle special cases when network namespaces are mixed in something other then a 1-1 correspondence with other namespaces. Like the one you were concerned with in unshare. Handling this case means everything just works.
So it may be a touch harder to implement but because we don't add special rules it is much easier to review.
Very interesting. Thank you for taking the time to answer.
-- Daniel
Quoted 20 lines · Eric W. Biederman
Quoted 4 lines · Daniel Lezcano
Yes, it will work.
Do we want to be inside a network namespace and to use a socket belonging to another network namespace ? If yes, then my remark is irrelevant.
Yes we do.
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
Shall we close all fd sockets when doing an unshare ? like a close-on-exec behavior ?
I think adopting that policy would dramatically reduce the usefulness of network namespaces.
Making the mix and match cases gives the implementation much more flexibility and it doesn't appear that hard right now.
I am curious, why such functionality is useful ?
There are several reasons. Partly it is the principle of building general purpose tools that can be used in a flexible way.
Quoted 6 lines
The biggest practical use I can see is that a control program outside of a network namespace can configure and setup someone else's network stack, perhaps preventing the need to enter someone else's container.
Another use is having a socket in an original network namespace for doing a stdin/stdout style connections.
this is also required in the HPC world. batch managers and MPI frameworks often redirect stdios on the socket which was used to remotely execute the job. Now, if we introduce a container around the job to be able to migrate it, we are in the same scenario.
that socket is in the original network namespace and the fds are from processes living in a container.
C.
Quoted 21 lines
The planetlab folks are actually actively using this functionality already, and there was a thread several months ago about how this functionality was important and how they were using it.
This also preserves normal unix file descriptor passing semantics.
A final reason for it is that it removes the need for a lot of brittle special cases when network namespaces are mixed in something other then a 1-1 correspondence with other namespaces. Like the one you were concerned with in unshare. Handling this case means everything just works.
So it may be a touch harder to implement but because we don't add special rules it is much easier to review.
Eric
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers