Switching into a network namespace does not change /sys/class/net?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
The Linux man page for network namespaces(7) says:
Network namespaces provide isolation of the system resources associated with networking: [...], the /sys/class/net directory, [...].
However, simply switching into a different network namespace doesn't seem to change the contents of /sys/class/net
(see below for how to reproduce). Am I just mistaken here in thinking that the setns()
into the network namespace is already sufficient? Is it always necessary to remount /sys
in order to get the correct /sys/class/net
matching the currently joined network namespace? Or am I missing something else here?
Example to Reproduce
Take an *ubuntu system, find the PID of the rtkit-daemon, enter the daemon's network namespace, show its network interfaces, and then check /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# ls /sys/class/net
docker0 enp3s0 lo lxcbr0 ...
Please notice that while ip link show
correctly only shows lo
, /sys/class/net
shows all network interfaces visible in the "root" network namespace (and "root" mount namespace).
In the case of rtkit-daemon
also entering the mount namespace of it doesn't make a difference: sudo nsenter -t $PID -n -m
and then ls /sys/class/net
still shows network interfaces not present in the network namespace.
"Fix"
Many kudos to @Danila Kiver for explaining what really is going on behind the Linux kernel scenes. Remounting sysfs
while the correct network namespace is joined will show the correct entries in /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# MNT=`mktemp -d`
# mount -t sysfs none $MNT
# ls $MNT/class/net/
lo
# umount $MNT
# rmdir $MNT
# exit
So this now yields the correct results in /sys/class/net
.
linux namespace network-namespaces
add a comment |Â
up vote
2
down vote
favorite
The Linux man page for network namespaces(7) says:
Network namespaces provide isolation of the system resources associated with networking: [...], the /sys/class/net directory, [...].
However, simply switching into a different network namespace doesn't seem to change the contents of /sys/class/net
(see below for how to reproduce). Am I just mistaken here in thinking that the setns()
into the network namespace is already sufficient? Is it always necessary to remount /sys
in order to get the correct /sys/class/net
matching the currently joined network namespace? Or am I missing something else here?
Example to Reproduce
Take an *ubuntu system, find the PID of the rtkit-daemon, enter the daemon's network namespace, show its network interfaces, and then check /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# ls /sys/class/net
docker0 enp3s0 lo lxcbr0 ...
Please notice that while ip link show
correctly only shows lo
, /sys/class/net
shows all network interfaces visible in the "root" network namespace (and "root" mount namespace).
In the case of rtkit-daemon
also entering the mount namespace of it doesn't make a difference: sudo nsenter -t $PID -n -m
and then ls /sys/class/net
still shows network interfaces not present in the network namespace.
"Fix"
Many kudos to @Danila Kiver for explaining what really is going on behind the Linux kernel scenes. Remounting sysfs
while the correct network namespace is joined will show the correct entries in /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# MNT=`mktemp -d`
# mount -t sysfs none $MNT
# ls $MNT/class/net/
lo
# umount $MNT
# rmdir $MNT
# exit
So this now yields the correct results in /sys/class/net
.
linux namespace network-namespaces
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
The Linux man page for network namespaces(7) says:
Network namespaces provide isolation of the system resources associated with networking: [...], the /sys/class/net directory, [...].
However, simply switching into a different network namespace doesn't seem to change the contents of /sys/class/net
(see below for how to reproduce). Am I just mistaken here in thinking that the setns()
into the network namespace is already sufficient? Is it always necessary to remount /sys
in order to get the correct /sys/class/net
matching the currently joined network namespace? Or am I missing something else here?
Example to Reproduce
Take an *ubuntu system, find the PID of the rtkit-daemon, enter the daemon's network namespace, show its network interfaces, and then check /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# ls /sys/class/net
docker0 enp3s0 lo lxcbr0 ...
Please notice that while ip link show
correctly only shows lo
, /sys/class/net
shows all network interfaces visible in the "root" network namespace (and "root" mount namespace).
In the case of rtkit-daemon
also entering the mount namespace of it doesn't make a difference: sudo nsenter -t $PID -n -m
and then ls /sys/class/net
still shows network interfaces not present in the network namespace.
"Fix"
Many kudos to @Danila Kiver for explaining what really is going on behind the Linux kernel scenes. Remounting sysfs
while the correct network namespace is joined will show the correct entries in /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# MNT=`mktemp -d`
# mount -t sysfs none $MNT
# ls $MNT/class/net/
lo
# umount $MNT
# rmdir $MNT
# exit
So this now yields the correct results in /sys/class/net
.
linux namespace network-namespaces
The Linux man page for network namespaces(7) says:
Network namespaces provide isolation of the system resources associated with networking: [...], the /sys/class/net directory, [...].
However, simply switching into a different network namespace doesn't seem to change the contents of /sys/class/net
(see below for how to reproduce). Am I just mistaken here in thinking that the setns()
into the network namespace is already sufficient? Is it always necessary to remount /sys
in order to get the correct /sys/class/net
matching the currently joined network namespace? Or am I missing something else here?
Example to Reproduce
Take an *ubuntu system, find the PID of the rtkit-daemon, enter the daemon's network namespace, show its network interfaces, and then check /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# ls /sys/class/net
docker0 enp3s0 lo lxcbr0 ...
Please notice that while ip link show
correctly only shows lo
, /sys/class/net
shows all network interfaces visible in the "root" network namespace (and "root" mount namespace).
In the case of rtkit-daemon
also entering the mount namespace of it doesn't make a difference: sudo nsenter -t $PID -n -m
and then ls /sys/class/net
still shows network interfaces not present in the network namespace.
"Fix"
Many kudos to @Danila Kiver for explaining what really is going on behind the Linux kernel scenes. Remounting sysfs
while the correct network namespace is joined will show the correct entries in /sys/class/net
:
$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# MNT=`mktemp -d`
# mount -t sysfs none $MNT
# ls $MNT/class/net/
lo
# umount $MNT
# rmdir $MNT
# exit
So this now yields the correct results in /sys/class/net
.
linux namespace network-namespaces
edited Jul 20 at 15:09
asked Jul 18 at 14:59
TheDiveO
22310
22310
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
Let's look into man 5 sysfs
:
/sys/class/net
Each of the entries in this directory is a symbolic link representing
one of the real or virtual networking devices that are visible in
the network namespace of the process that is accessing the directory.
So, according to this manpage, the output of ls /sys/class/net
must depend on the network namespace of the ls
process. But... Actual behavior does not seem to be as described in this manpage. There is a nice kernel documentation about how it works.
Each sysfs
mount has a namespace tag associated with it. This tag is set when sysfs gets mounted and depends on the network namespace of the calling process. Each sysfs entry (e.g. an entry in /sys/class/net
) also may have a namespace tag associated with it.
When you iterate over the sysfs directory, the kernel obtains the namespace tag of the sysfs mount, and then it iterates over the entries, filtering out those which have different namespace tag.
So, it turns out that the results of iterating over the /sys/class/net
depend on the network namespace of the process which initiated /sys
mount rather than on the network namespace of the current process, thus, you must always mount /sys
in the current network namespace (from any process belonging to this namespace) to see the correct results.
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
By "...you must always mount/sys
" does the "you" refer to the (inquiring) process trying to access/sys/class/net
-- and not the process creating the network namespace, correct?
â TheDiveO
Jul 20 at 9:07
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Let's look into man 5 sysfs
:
/sys/class/net
Each of the entries in this directory is a symbolic link representing
one of the real or virtual networking devices that are visible in
the network namespace of the process that is accessing the directory.
So, according to this manpage, the output of ls /sys/class/net
must depend on the network namespace of the ls
process. But... Actual behavior does not seem to be as described in this manpage. There is a nice kernel documentation about how it works.
Each sysfs
mount has a namespace tag associated with it. This tag is set when sysfs gets mounted and depends on the network namespace of the calling process. Each sysfs entry (e.g. an entry in /sys/class/net
) also may have a namespace tag associated with it.
When you iterate over the sysfs directory, the kernel obtains the namespace tag of the sysfs mount, and then it iterates over the entries, filtering out those which have different namespace tag.
So, it turns out that the results of iterating over the /sys/class/net
depend on the network namespace of the process which initiated /sys
mount rather than on the network namespace of the current process, thus, you must always mount /sys
in the current network namespace (from any process belonging to this namespace) to see the correct results.
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
By "...you must always mount/sys
" does the "you" refer to the (inquiring) process trying to access/sys/class/net
-- and not the process creating the network namespace, correct?
â TheDiveO
Jul 20 at 9:07
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
add a comment |Â
up vote
2
down vote
accepted
Let's look into man 5 sysfs
:
/sys/class/net
Each of the entries in this directory is a symbolic link representing
one of the real or virtual networking devices that are visible in
the network namespace of the process that is accessing the directory.
So, according to this manpage, the output of ls /sys/class/net
must depend on the network namespace of the ls
process. But... Actual behavior does not seem to be as described in this manpage. There is a nice kernel documentation about how it works.
Each sysfs
mount has a namespace tag associated with it. This tag is set when sysfs gets mounted and depends on the network namespace of the calling process. Each sysfs entry (e.g. an entry in /sys/class/net
) also may have a namespace tag associated with it.
When you iterate over the sysfs directory, the kernel obtains the namespace tag of the sysfs mount, and then it iterates over the entries, filtering out those which have different namespace tag.
So, it turns out that the results of iterating over the /sys/class/net
depend on the network namespace of the process which initiated /sys
mount rather than on the network namespace of the current process, thus, you must always mount /sys
in the current network namespace (from any process belonging to this namespace) to see the correct results.
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
By "...you must always mount/sys
" does the "you" refer to the (inquiring) process trying to access/sys/class/net
-- and not the process creating the network namespace, correct?
â TheDiveO
Jul 20 at 9:07
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Let's look into man 5 sysfs
:
/sys/class/net
Each of the entries in this directory is a symbolic link representing
one of the real or virtual networking devices that are visible in
the network namespace of the process that is accessing the directory.
So, according to this manpage, the output of ls /sys/class/net
must depend on the network namespace of the ls
process. But... Actual behavior does not seem to be as described in this manpage. There is a nice kernel documentation about how it works.
Each sysfs
mount has a namespace tag associated with it. This tag is set when sysfs gets mounted and depends on the network namespace of the calling process. Each sysfs entry (e.g. an entry in /sys/class/net
) also may have a namespace tag associated with it.
When you iterate over the sysfs directory, the kernel obtains the namespace tag of the sysfs mount, and then it iterates over the entries, filtering out those which have different namespace tag.
So, it turns out that the results of iterating over the /sys/class/net
depend on the network namespace of the process which initiated /sys
mount rather than on the network namespace of the current process, thus, you must always mount /sys
in the current network namespace (from any process belonging to this namespace) to see the correct results.
Let's look into man 5 sysfs
:
/sys/class/net
Each of the entries in this directory is a symbolic link representing
one of the real or virtual networking devices that are visible in
the network namespace of the process that is accessing the directory.
So, according to this manpage, the output of ls /sys/class/net
must depend on the network namespace of the ls
process. But... Actual behavior does not seem to be as described in this manpage. There is a nice kernel documentation about how it works.
Each sysfs
mount has a namespace tag associated with it. This tag is set when sysfs gets mounted and depends on the network namespace of the calling process. Each sysfs entry (e.g. an entry in /sys/class/net
) also may have a namespace tag associated with it.
When you iterate over the sysfs directory, the kernel obtains the namespace tag of the sysfs mount, and then it iterates over the entries, filtering out those which have different namespace tag.
So, it turns out that the results of iterating over the /sys/class/net
depend on the network namespace of the process which initiated /sys
mount rather than on the network namespace of the current process, thus, you must always mount /sys
in the current network namespace (from any process belonging to this namespace) to see the correct results.
edited Jul 20 at 10:29
answered Jul 20 at 8:46
Danila Kiver
303111
303111
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
By "...you must always mount/sys
" does the "you" refer to the (inquiring) process trying to access/sys/class/net
-- and not the process creating the network namespace, correct?
â TheDiveO
Jul 20 at 9:07
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
add a comment |Â
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
By "...you must always mount/sys
" does the "you" refer to the (inquiring) process trying to access/sys/class/net
-- and not the process creating the network namespace, correct?
â TheDiveO
Jul 20 at 9:07
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
wow! I had wished for such a comprehensive answer, but didn't dare to expect it. Thank you very much!
â TheDiveO
Jul 20 at 9:04
By "...you must always mount
/sys
" does the "you" refer to the (inquiring) process trying to access /sys/class/net
-- and not the process creating the network namespace, correct?â TheDiveO
Jul 20 at 9:07
By "...you must always mount
/sys
" does the "you" refer to the (inquiring) process trying to access /sys/class/net
-- and not the process creating the network namespace, correct?â TheDiveO
Jul 20 at 9:07
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@TheDiveO I mean any process in the network namespace of the inquiring process (including this process itself). That seems to be enough.
â Danila Kiver
Jul 20 at 9:51
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
@sourcejedi sure, I will change references to the specific commit.
â Danila Kiver
Jul 20 at 9:52
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f457025%2fswitching-into-a-network-namespace-does-not-change-sys-class-net%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password