From: Dilip Daya <dilip.daya@hp.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: network-namespace and unix-domain-sockets
Date: Fri, 28 Sep 2012 15:51:42 -0400 [thread overview]
Message-ID: <1348861902.32187.18.camel@pro6455b.example.com> (raw)
In-Reply-To: <87ehlmkku5.fsf@xmission.com>
Hi Eric,
I very much appreciate your quick response!. I found it:
<http://lists.linux-foundation.org/pipermail/containers/2010-June/024725.html>
Thanking you for your time and effort.
-DilipD.
On Fri, 2012-09-28 at 12:29 -0700, Eric W. Biederman wrote:
> Dilip Daya <dilip.daya@hp.com> writes:
>
> > Hi Eric,
> >
> > => kernel 3.6.0-rc6 + network-namespace + unix-domain-sockets
> >
> > srv/cli sample programs at:
> > <http://tkhanson.net/cgit.cgi/misc.git/plain/unixdomain/Unix_domain_sockets.html>
> > Executing UNIX domain sockets between two network-namespaces fails but
> > successful if both srv and cli are executed within a network-namespace.
> >
> > Test results:
> >
> > (1) Executing both srv and cli within default/host network-namespace:
> >
> > On host/default netns:
> > # ./cli
> > testing...
> > ^C
> >
> > On host/default netns:
> > # ./srv
> > read 11 bytes: testing...
> >
> > EOF
> >
> >
> > (2) Executing srv in default/host netns and cli within netns named
> > netns0:
> >
> > On host/default netns:
> > # ip netns
> > netns1
> > netns0
> >
> > On host/default netns:
> > # ./srv
> >
> > Within netns name netns0:
> > # ip netns exec netns0 ./cli
> > connect error: Connection refused
>
> Yes that is correct behavior.
>
> > => I find difference between __unix_find_socket_byname() and
> > *unix_find_socket_byinode()
> >
> > ---
> > if (!net_eq(sock_net(s), net))
> > continue;
> > ---
> >
> > => Is there an explanation for why __unix_find_socket_byname() was left
> > netns aware and *unix_find_socket_byinode() is not netns aware ?
>
> The abstract namespace will cause two sockets with the same name
> in different network namespaces to conflict.
>
> The network namespace a socket is in is irrelevant for purposes of
> conflicts on the filesystem.
>
> There is also a detailed commit message that was written at the time
> the per network namespace restrictions were relaxed on
> unix_find_socket_byinode if you would like to read it.
>
> > => Please see attached patch. Is this valid? or will it break something?
> > I've tested network namespaces with this patch applied and I did not
> > find any issues.
>
> Totally invalid.
>
> Eric
prev parent reply other threads:[~2012-09-28 19:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-28 14:12 network-namespace and unix-domain-sockets Dilip Daya
2012-09-28 19:29 ` Eric W. Biederman
2012-09-28 19:51 ` Dilip Daya [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1348861902.32187.18.camel@pro6455b.example.com \
--to=dilip.daya@hp.com \
--cc=ebiederm@xmission.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.