Switching into a network namespace does not change /sys/class/net?

The name of the pictureThe name of the pictureThe name of the pictureClash 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.







share|improve this question



























    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.







    share|improve this question























      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.







      share|improve this question













      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.









      share|improve this question












      share|improve this question




      share|improve this question








      edited Jul 20 at 15:09
























      asked Jul 18 at 14:59









      TheDiveO

      22310




      22310




















          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.






          share|improve this answer























          • 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










          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          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






























          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.






          share|improve this answer























          • 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














          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.






          share|improve this answer























          • 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












          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.






          share|improve this answer















          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.







          share|improve this answer















          share|improve this answer



          share|improve this answer








          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
















          • 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












           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          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













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay