Kari Hurtta [EMAIL PROTECTED] writes in gmane.linux.network:
[EMAIL PROTECTED] (Eric W. Biederman) writes in gmane.linux.network:
Ok. So on this point we agree. Full isolation at the network device/L2
level
is desirable and no one is opposed to that.
There is however a strong feeling especially for the case of application
containers that something more focused on what a non-privileged process can
use and deal with would be nice. The ``L3'' case.
I agree that has potential but I worry about 2 things.
- Premature optimization.
- A poor choice of semantics.
- Feature creep leading to insane semantics.
I feel there is something in the L3 arguments as well and it sounds
like it would be a good idea to flush out the semantics.
For full network isolation we have the case that every process,
every socket, and every network device belongs to a network namespace.
This is enough to derive the network namespace for all other user
visible data structures, and to a large extent to define their semantics.
We still need a definition of the non-privileged case, that is compatible
with the former definition.
.
What unprivileged user space gets to manipulate are sockets. So perhaps
we can break our model into a network socket namespace and network device
namespace.
I would define it so that for each socket there is exactly one network
socket namespace. And for each network socket namespace there is exactly
one network device namespace.
The network socket namespace would be concerned with the rules for deciding
which local addresses a socket can connect/accept/bind to.
The network device namespace would be concerned with everything else.
There need decide one thing: What is connection between namespaces?
- Connection between the network device namespaces is bridge.
- What (socket) is connection between the network socket namespaces?
Connection inside on name namespace is clear I think.
- Connection inside of network device namespaces is loopback device.
- Connection inside of network socket namespaces is socket
using loopback address(es)?
On other hand bridge between the network device namespaces need to set
on parent namespace.
So it is logical that connecting socket between network socket namespaces
is set on parent namespace.So connecting socket is any socket created
on parent namespace? (socketpair() for example? )
( Currently socketpair() allows only create AF_UNIX sockects, which
are not part of network socket namespace, I think)
/ Kari Hurtta
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
