Eric W. Biederman wrote:
When an outgoing packet has the loopback destination addres, the
skbuff is filled with the network namespace. So the loopback packets
never go outside the namespace. This approach facilitate the migration
of loopback because identification is done by network namespace
On Tue, Jun 27, 2006 at 10:33:48PM -0600, Eric W. Biederman wrote:
Something to examine here is that if both network devices and sockets
are tagged does that still allow implicit network namespace passing.
I think avoiding implicit network namespace passing expresses more
power/flexibility
Eric W. Biederman wrote:
In general it is possible to get file descriptors opened by someone
else because unix domain sockets allow file descriptor passing. Similarly
I think there are cases in both unshare and fork that allows you to sockets
open before you entered a namespace.
This is
Sam Vilain [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
In general it is possible to get file descriptors opened by someone
else because unix domain sockets allow file descriptor passing. Similarly
I think there are cases in both unshare and fork that allows you to sockets
open before
Eric W. Biederman wrote:
Despite what it might look like unix domain sockets do not live in the
filesystem. They store a cookie in the filesystem that roughly
corresponds to the port number of an AF_INET socket. When you open a
socket the lookup is done by the cookie retrieved from the
Hello,
Eric W. Biederman wrote:
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific network namespace.
- How we mark a socket as belonging to a
Hi Eric,
On Tue, Jun 27, 2006 at 10:20:32PM -0600, Eric W. Biederman wrote:
Andrey Savochkin [EMAIL PROTECTED] writes:
[snip]
My first patchset covers devices but not sockets.
The only difference from what you're suggesting is ipv4 routing.
For me, it is not less important than devices and
Cedric Le Goater [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Despite what it might look like unix domain sockets do not live in the
filesystem. They store a cookie in the filesystem that roughly
corresponds to the port number of an AF_INET socket. When you open a
socket the lookup
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
I think we're reaching the limits of namespaces. It would be much easier
with a container id in each kernel object we want to isolate.
Nope. Except for the fact that names are peculiar (sockets, network
device names, IP address, routes...)
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
I think we're reaching the limits of namespaces. It would be much easier
with a container id in each kernel object we want to isolate.
Nope. Except for the fact that names are peculiar (sockets,
Cedric Le Goater [EMAIL PROTECTED] writes:
How that proposal differs from the initial Daniel's patchset ? how far was
that patchset to reach a similar agreement ?
My impression is as follows. The OpenVz implementation and mine work
on the same basic principles of handling the network stack at
Andrey Savochkin [EMAIL PROTECTED] writes:
Ok, fine.
Now I'm working on socket code.
We still have a question about implicit vs explicit function parameters.
This question becomes more important for sockets: if we want to allow to use
sockets belonging to namespaces other than the current
Hi Eric,
On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
Andrey Savochkin [EMAIL PROTECTED] writes:
One possible option to resolve this question is to show 2 relatively short
patches just introducing namespaces for sockets in 2 ways: with explicit
function parameters
On Wed, Jun 28, 2006 at 09:22:40PM +0400, Andrey Savochkin wrote:
Hi Eric,
On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
Andrey Savochkin [EMAIL PROTECTED] writes:
One possible option to resolve this question is to show 2
relatively short patches just
Andrey Savochkin [EMAIL PROTECTED] writes:
A general pattern that happens in cleanups is the discovery
that code using an old interface in a problematic way really
could be done much better another way. I didn't dig enough
to see if that was the case in any of the code that you changed.
Andrey Savochkin [EMAIL PROTECTED] writes:
Hi Eric,
On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
Andrey Savochkin [EMAIL PROTECTED] writes:
One possible option to resolve this question is to show 2 relatively short
patches just introducing namespaces for sockets in
Andrey Savochkin [EMAIL PROTECTED] writes:
In a slightly different vein your second patch introduced a lot
of #ifdef CONFIG_NET_NS in C files. That is something we need to look
closely
at.
So I think the abstraction that we use to access per network namespace
variables needs some work
On Wed, Jun 28, 2006 at 12:14:41PM -0600, Eric W. Biederman wrote:
Andrey Savochkin [EMAIL PROTECTED] writes:
On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
Andrey Savochkin [EMAIL PROTECTED] writes:
One possible option to resolve this question is to show 2
Andrey Savochkin wrote:
Ok, fine.
Now I'm working on socket code.
We still have a question about implicit vs explicit function parameters.
This question becomes more important for sockets: if we want to allow to use
sockets belonging to namespaces other than the current one, we need to do
On Wed, 28 Jun 2006, Daniel Lezcano wrote:
The attached patch can have some part interesting for you for the socket
tagging. It is in the IPV4 isolation (part 5/6). With this and the private
routing table you will probably have a good IPV4 isolation.
Please send patches inline, do not attach
James Morris [EMAIL PROTECTED] writes:
On Wed, 28 Jun 2006, Daniel Lezcano wrote:
The attached patch can have some part interesting for you for the socket
tagging. It is in the IPV4 isolation (part 5/6). With this and the private
routing table you will probably have a good IPV4 isolation.
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific network namespace.
- How we mark a socket as belonging to a specific network namespace.
As part
Eric,
On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific network namespace.
Andrey Savochkin wrote:
On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific
Andrey Savochkin [EMAIL PROTECTED] writes:
Eric,
On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device
Sam Vilain [EMAIL PROTECTED] writes:
It sounds then like it would be a good start to have general socket
namespaces, if it would merge more easily - perhaps then network device
namespaces would fall into place more easily.
I guess I really see both sockets and devices as the fundamental
26 matches
Mail list logo
