network-namespace and unix-domain-sockets

[Dilip Daya]

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


=> 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 ?

=> 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.

-DilipD.

[Eric W. Biederman]

Post by Dilip Daya
Hi Eric,
=> kernel 3.6.0-rc6 + network-namespace + unix-domain-sockets
<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.
# ./cli
testing...
^C
# ./srv
read 11 bytes: testing...
EOF
(2) Executing srv in default/host netns and cli within netns named
# ip netns
netns1
netns0
# ./srv
# ip netns exec netns0 ./cli
connect error: Connection refused

Yes that is correct behavior.

Post by Dilip Daya
=> 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.

Post by Dilip Daya
=> 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

[Dilip Daya]

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.

Post by Eric W. Biederman

Post by Dilip Daya
Hi Eric,
=> kernel 3.6.0-rc6 + network-namespace + unix-domain-sockets
<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.
# ./cli
testing...
^C
# ./srv
read 11 bytes: testing...
EOF
(2) Executing srv in default/host netns and cli within netns named
# ip netns
netns1
netns0
# ./srv
# ip netns exec netns0 ./cli
connect error: Connection refused

Yes that is correct behavior.

Post by Dilip Daya
=> 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.

Post by Dilip Daya
=> 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