How to get the Linux network namespace for a tap/tun device referenced in /proc/[PID]/fdinfo/[FD]?

Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I want to correctly match TAP/TUN devices with the processes they are using, and I want to do this from outside of these processes using TAP/TUN devices (that is, I cannot issue any ioctl()s because I don't have access to a particular file descriptor inside its process itself).
I'm aware of the answers to How to find the connection between tap interface and its file descriptor?, that is: /proc/[PID]/fdinfo/[FD] has an additional iff: key-value pair that gives the name of the corresponding TAP/TUN network interface.
However, there's a problem with network namespaces, especially when TAP/TUN network interfaces get moved around network namespaces after their user-space processes have attached to them; for instance (here, tapclient is a simple variation of a34729t's tunclient.c, which accepts a tap network name and attaches to it):
$ sudo ip tuntap add tap123 mode tap
$ sudo tapclient tap123 &
$ sudo ip netns add fooz
$ sudo ip link set tap123 netns fooz
$ PID=$(ps faux | grep tapclient | grep -v -e sudo -e grep | awk 'print $2')
$ sudo cat /proc/$PID/fdinfo/3
...which then gives: iff: tap123 -- but not the network namespace where the tap123 network interface is currently located in.
Of course, tap123 can be located by iterating over all network namespaces and looking for a matching network interface inside one of them. Unfortunately, there might be duplicate names, such as when creating another tap123 in the host namespace after we've moved the first one of this name into the fooz network namespace above:
$ sudo ip tuntap add tap123 mode tap
$ ip link show tap123
$ sudo ip netns exec fooz ip link show tap123
So we now have two tap123s in separate network namespaces, and fdinfo only gives us an ambiguous iff: tap123.
Unfortunately, looking at the /proc/$PID/ns/net network namespace of the tapclient won't help either, since that doesn't match the current network namespace of tap123 any longer:
$ findmnt -t nsfs | grep /run/netns/fooz
$ sudo readlink /proc/$PID/ns/net
For instance, this gives net:[4026532591] versus net:[4026531993].
It there a way to unambiguously match the tapclient process with the correct tap123 network interface instance it is attached to?
linux network-namespaces tap
add a comment |
I want to correctly match TAP/TUN devices with the processes they are using, and I want to do this from outside of these processes using TAP/TUN devices (that is, I cannot issue any ioctl()s because I don't have access to a particular file descriptor inside its process itself).
I'm aware of the answers to How to find the connection between tap interface and its file descriptor?, that is: /proc/[PID]/fdinfo/[FD] has an additional iff: key-value pair that gives the name of the corresponding TAP/TUN network interface.
However, there's a problem with network namespaces, especially when TAP/TUN network interfaces get moved around network namespaces after their user-space processes have attached to them; for instance (here, tapclient is a simple variation of a34729t's tunclient.c, which accepts a tap network name and attaches to it):
$ sudo ip tuntap add tap123 mode tap
$ sudo tapclient tap123 &
$ sudo ip netns add fooz
$ sudo ip link set tap123 netns fooz
$ PID=$(ps faux | grep tapclient | grep -v -e sudo -e grep | awk 'print $2')
$ sudo cat /proc/$PID/fdinfo/3
...which then gives: iff: tap123 -- but not the network namespace where the tap123 network interface is currently located in.
Of course, tap123 can be located by iterating over all network namespaces and looking for a matching network interface inside one of them. Unfortunately, there might be duplicate names, such as when creating another tap123 in the host namespace after we've moved the first one of this name into the fooz network namespace above:
$ sudo ip tuntap add tap123 mode tap
$ ip link show tap123
$ sudo ip netns exec fooz ip link show tap123
So we now have two tap123s in separate network namespaces, and fdinfo only gives us an ambiguous iff: tap123.
Unfortunately, looking at the /proc/$PID/ns/net network namespace of the tapclient won't help either, since that doesn't match the current network namespace of tap123 any longer:
$ findmnt -t nsfs | grep /run/netns/fooz
$ sudo readlink /proc/$PID/ns/net
For instance, this gives net:[4026532591] versus net:[4026531993].
It there a way to unambiguously match the tapclient process with the correct tap123 network interface instance it is attached to?
linux network-namespaces tap
Note that there'sip netns identify $PIDthat should give you the net namespace of$PIDwithout you having to look at nsfs inode numbers (andip netns pids foozto go the other way), but they don't seem to find anything either. Sounds like a kernel bug.
– TooTea
Mar 7 at 10:40
@TooTeaip netns identify $PIDis doing nothing more than taking/proc/$PID/ns/netand then trying to match only against its own list of bind-mounted symbolic network namespace names. Unfortunately, that's most of the time rather pointless as few are using iproute2's bindmount positions. My example is just usingip netns ...to give an easily reproducable example to check the underlying mechanisms, but it's not a typical deployment situation.
– TheDiveO
Mar 7 at 14:16
add a comment |
I want to correctly match TAP/TUN devices with the processes they are using, and I want to do this from outside of these processes using TAP/TUN devices (that is, I cannot issue any ioctl()s because I don't have access to a particular file descriptor inside its process itself).
I'm aware of the answers to How to find the connection between tap interface and its file descriptor?, that is: /proc/[PID]/fdinfo/[FD] has an additional iff: key-value pair that gives the name of the corresponding TAP/TUN network interface.
However, there's a problem with network namespaces, especially when TAP/TUN network interfaces get moved around network namespaces after their user-space processes have attached to them; for instance (here, tapclient is a simple variation of a34729t's tunclient.c, which accepts a tap network name and attaches to it):
$ sudo ip tuntap add tap123 mode tap
$ sudo tapclient tap123 &
$ sudo ip netns add fooz
$ sudo ip link set tap123 netns fooz
$ PID=$(ps faux | grep tapclient | grep -v -e sudo -e grep | awk 'print $2')
$ sudo cat /proc/$PID/fdinfo/3
...which then gives: iff: tap123 -- but not the network namespace where the tap123 network interface is currently located in.
Of course, tap123 can be located by iterating over all network namespaces and looking for a matching network interface inside one of them. Unfortunately, there might be duplicate names, such as when creating another tap123 in the host namespace after we've moved the first one of this name into the fooz network namespace above:
$ sudo ip tuntap add tap123 mode tap
$ ip link show tap123
$ sudo ip netns exec fooz ip link show tap123
So we now have two tap123s in separate network namespaces, and fdinfo only gives us an ambiguous iff: tap123.
Unfortunately, looking at the /proc/$PID/ns/net network namespace of the tapclient won't help either, since that doesn't match the current network namespace of tap123 any longer:
$ findmnt -t nsfs | grep /run/netns/fooz
$ sudo readlink /proc/$PID/ns/net
For instance, this gives net:[4026532591] versus net:[4026531993].
It there a way to unambiguously match the tapclient process with the correct tap123 network interface instance it is attached to?
linux network-namespaces tap
I want to correctly match TAP/TUN devices with the processes they are using, and I want to do this from outside of these processes using TAP/TUN devices (that is, I cannot issue any ioctl()s because I don't have access to a particular file descriptor inside its process itself).
I'm aware of the answers to How to find the connection between tap interface and its file descriptor?, that is: /proc/[PID]/fdinfo/[FD] has an additional iff: key-value pair that gives the name of the corresponding TAP/TUN network interface.
However, there's a problem with network namespaces, especially when TAP/TUN network interfaces get moved around network namespaces after their user-space processes have attached to them; for instance (here, tapclient is a simple variation of a34729t's tunclient.c, which accepts a tap network name and attaches to it):
$ sudo ip tuntap add tap123 mode tap
$ sudo tapclient tap123 &
$ sudo ip netns add fooz
$ sudo ip link set tap123 netns fooz
$ PID=$(ps faux | grep tapclient | grep -v -e sudo -e grep | awk 'print $2')
$ sudo cat /proc/$PID/fdinfo/3
...which then gives: iff: tap123 -- but not the network namespace where the tap123 network interface is currently located in.
Of course, tap123 can be located by iterating over all network namespaces and looking for a matching network interface inside one of them. Unfortunately, there might be duplicate names, such as when creating another tap123 in the host namespace after we've moved the first one of this name into the fooz network namespace above:
$ sudo ip tuntap add tap123 mode tap
$ ip link show tap123
$ sudo ip netns exec fooz ip link show tap123
So we now have two tap123s in separate network namespaces, and fdinfo only gives us an ambiguous iff: tap123.
Unfortunately, looking at the /proc/$PID/ns/net network namespace of the tapclient won't help either, since that doesn't match the current network namespace of tap123 any longer:
$ findmnt -t nsfs | grep /run/netns/fooz
$ sudo readlink /proc/$PID/ns/net
For instance, this gives net:[4026532591] versus net:[4026531993].
It there a way to unambiguously match the tapclient process with the correct tap123 network interface instance it is attached to?
linux network-namespaces tap
linux network-namespaces tap
edited Mar 7 at 19:48
TheDiveO
asked Mar 7 at 8:36
TheDiveOTheDiveO
273111
273111
Note that there'sip netns identify $PIDthat should give you the net namespace of$PIDwithout you having to look at nsfs inode numbers (andip netns pids foozto go the other way), but they don't seem to find anything either. Sounds like a kernel bug.
– TooTea
Mar 7 at 10:40
@TooTeaip netns identify $PIDis doing nothing more than taking/proc/$PID/ns/netand then trying to match only against its own list of bind-mounted symbolic network namespace names. Unfortunately, that's most of the time rather pointless as few are using iproute2's bindmount positions. My example is just usingip netns ...to give an easily reproducable example to check the underlying mechanisms, but it's not a typical deployment situation.
– TheDiveO
Mar 7 at 14:16
add a comment |
Note that there'sip netns identify $PIDthat should give you the net namespace of$PIDwithout you having to look at nsfs inode numbers (andip netns pids foozto go the other way), but they don't seem to find anything either. Sounds like a kernel bug.
– TooTea
Mar 7 at 10:40
@TooTeaip netns identify $PIDis doing nothing more than taking/proc/$PID/ns/netand then trying to match only against its own list of bind-mounted symbolic network namespace names. Unfortunately, that's most of the time rather pointless as few are using iproute2's bindmount positions. My example is just usingip netns ...to give an easily reproducable example to check the underlying mechanisms, but it's not a typical deployment situation.
– TheDiveO
Mar 7 at 14:16
Note that there's
ip netns identify $PID that should give you the net namespace of $PID without you having to look at nsfs inode numbers (and ip netns pids fooz to go the other way), but they don't seem to find anything either. Sounds like a kernel bug.– TooTea
Mar 7 at 10:40
Note that there's
ip netns identify $PID that should give you the net namespace of $PID without you having to look at nsfs inode numbers (and ip netns pids fooz to go the other way), but they don't seem to find anything either. Sounds like a kernel bug.– TooTea
Mar 7 at 10:40
@TooTea
ip netns identify $PID is doing nothing more than taking /proc/$PID/ns/net and then trying to match only against its own list of bind-mounted symbolic network namespace names. Unfortunately, that's most of the time rather pointless as few are using iproute2's bindmount positions. My example is just using ip netns ... to give an easily reproducable example to check the underlying mechanisms, but it's not a typical deployment situation.– TheDiveO
Mar 7 at 14:16
@TooTea
ip netns identify $PID is doing nothing more than taking /proc/$PID/ns/net and then trying to match only against its own list of bind-mounted symbolic network namespace names. Unfortunately, that's most of the time rather pointless as few are using iproute2's bindmount positions. My example is just using ip netns ... to give an easily reproducable example to check the underlying mechanisms, but it's not a typical deployment situation.– TheDiveO
Mar 7 at 14:16
add a comment |
1 Answer
1
active
oldest
votes
You can try matching the tun interface by its hardware address rather than by name (you can obtain that with ioctl(SIOCGIFHWADDR) on the tun/tap file descriptor).
I don't think there's anything simpler, otherwise a recent change like this (which adds the possibility of also retrieving the net namespace of the interface via the tun fd) wouldn't have been needed and accepted.
The newSIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!
– TheDiveO
Mar 7 at 14:22
The problem withSIOCGIFHWADDRand alsoSIOCGSKNSis rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue theSIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add anotherfdinfokey for giving correct network namespace information.
– TheDiveO
Mar 7 at 15:12
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info tofdinfo, and If usinggdbis an option, you can make a list of tap interfaces, and call the ioctl viagdbonly when necessary (when there really are duplicate names, etc).
– mosvy
Mar 7 at 20:17
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression thatSIOCGSKNSis strange as it returns the network namespace which was originally active when/dev/net/tunwas opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling intun.clooks slightly odd to me in places, especially when the stored original netns is passed but then ignored...
– TheDiveO
Mar 7 at 22:08
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
add a comment |
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504861%2fhow-to-get-the-linux-network-namespace-for-a-tap-tun-device-referenced-in-proc%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can try matching the tun interface by its hardware address rather than by name (you can obtain that with ioctl(SIOCGIFHWADDR) on the tun/tap file descriptor).
I don't think there's anything simpler, otherwise a recent change like this (which adds the possibility of also retrieving the net namespace of the interface via the tun fd) wouldn't have been needed and accepted.
The newSIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!
– TheDiveO
Mar 7 at 14:22
The problem withSIOCGIFHWADDRand alsoSIOCGSKNSis rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue theSIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add anotherfdinfokey for giving correct network namespace information.
– TheDiveO
Mar 7 at 15:12
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info tofdinfo, and If usinggdbis an option, you can make a list of tap interfaces, and call the ioctl viagdbonly when necessary (when there really are duplicate names, etc).
– mosvy
Mar 7 at 20:17
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression thatSIOCGSKNSis strange as it returns the network namespace which was originally active when/dev/net/tunwas opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling intun.clooks slightly odd to me in places, especially when the stored original netns is passed but then ignored...
– TheDiveO
Mar 7 at 22:08
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
add a comment |
You can try matching the tun interface by its hardware address rather than by name (you can obtain that with ioctl(SIOCGIFHWADDR) on the tun/tap file descriptor).
I don't think there's anything simpler, otherwise a recent change like this (which adds the possibility of also retrieving the net namespace of the interface via the tun fd) wouldn't have been needed and accepted.
The newSIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!
– TheDiveO
Mar 7 at 14:22
The problem withSIOCGIFHWADDRand alsoSIOCGSKNSis rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue theSIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add anotherfdinfokey for giving correct network namespace information.
– TheDiveO
Mar 7 at 15:12
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info tofdinfo, and If usinggdbis an option, you can make a list of tap interfaces, and call the ioctl viagdbonly when necessary (when there really are duplicate names, etc).
– mosvy
Mar 7 at 20:17
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression thatSIOCGSKNSis strange as it returns the network namespace which was originally active when/dev/net/tunwas opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling intun.clooks slightly odd to me in places, especially when the stored original netns is passed but then ignored...
– TheDiveO
Mar 7 at 22:08
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
add a comment |
You can try matching the tun interface by its hardware address rather than by name (you can obtain that with ioctl(SIOCGIFHWADDR) on the tun/tap file descriptor).
I don't think there's anything simpler, otherwise a recent change like this (which adds the possibility of also retrieving the net namespace of the interface via the tun fd) wouldn't have been needed and accepted.
You can try matching the tun interface by its hardware address rather than by name (you can obtain that with ioctl(SIOCGIFHWADDR) on the tun/tap file descriptor).
I don't think there's anything simpler, otherwise a recent change like this (which adds the possibility of also retrieving the net namespace of the interface via the tun fd) wouldn't have been needed and accepted.
edited Mar 7 at 11:06
answered Mar 7 at 10:42
mosvymosvy
9,0271833
9,0271833
The newSIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!
– TheDiveO
Mar 7 at 14:22
The problem withSIOCGIFHWADDRand alsoSIOCGSKNSis rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue theSIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add anotherfdinfokey for giving correct network namespace information.
– TheDiveO
Mar 7 at 15:12
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info tofdinfo, and If usinggdbis an option, you can make a list of tap interfaces, and call the ioctl viagdbonly when necessary (when there really are duplicate names, etc).
– mosvy
Mar 7 at 20:17
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression thatSIOCGSKNSis strange as it returns the network namespace which was originally active when/dev/net/tunwas opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling intun.clooks slightly odd to me in places, especially when the stored original netns is passed but then ignored...
– TheDiveO
Mar 7 at 22:08
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
add a comment |
The newSIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!
– TheDiveO
Mar 7 at 14:22
The problem withSIOCGIFHWADDRand alsoSIOCGSKNSis rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue theSIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add anotherfdinfokey for giving correct network namespace information.
– TheDiveO
Mar 7 at 15:12
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info tofdinfo, and If usinggdbis an option, you can make a list of tap interfaces, and call the ioctl viagdbonly when necessary (when there really are duplicate names, etc).
– mosvy
Mar 7 at 20:17
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression thatSIOCGSKNSis strange as it returns the network namespace which was originally active when/dev/net/tunwas opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling intun.clooks slightly odd to me in places, especially when the stored original netns is passed but then ignored...
– TheDiveO
Mar 7 at 22:08
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
The new
SIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!– TheDiveO
Mar 7 at 14:22
The new
SIOCGSKNSioctl() you link to looks very promising, I'll look into its code to see if it does the job I'm asking for. At first glance it looks like it does, as I noticed already that the TUN clone device fd has the network namespace associated, but this cannot be retrieved from userspace later. What I'm unsure is whether it really works under the example conditions laid out above. But an interesting link anyway, many thanks!– TheDiveO
Mar 7 at 14:22
The problem with
SIOCGIFHWADDR and also SIOCGSKNS is rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue the SIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add another fdinfo key for giving correct network namespace information.– TheDiveO
Mar 7 at 15:12
The problem with
SIOCGIFHWADDR and also SIOCGSKNS is rather that they need to be carried out on the original file descriptor because this fd's state is crucial here. Unfortunately, as unix.stackexchange.com/questions/74672/… points out, it's not really safely possible to duplicate the fd from the TAP/TUN user process to be used by someone else in order to issue the SIOCGKSNS. This leads me to believe that it's necessary to ask the kernel devs to be so kind as to add another fdinfo key for giving correct network namespace information.– TheDiveO
Mar 7 at 15:12
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info to
fdinfo, and If using gdb is an option, you can make a list of tap interfaces, and call the ioctl via gdb only when necessary (when there really are duplicate names, etc).– mosvy
Mar 7 at 20:17
I disagree that it's not "safely possible" to attach to a process with ptrace() and run any code in the context of that process (including sending fds with SCM_RIGHTS), but I don't have any nice and fast code to show right now. Until they add that info to
fdinfo, and If using gdb is an option, you can make a list of tap interfaces, and call the ioctl via gdb only when necessary (when there really are duplicate names, etc).– mosvy
Mar 7 at 20:17
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression that
SIOCGSKNS is strange as it returns the network namespace which was originally active when /dev/net/tun was opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling in tun.c looks slightly odd to me in places, especially when the stored original netns is passed but then ignored...– TheDiveO
Mar 7 at 22:08
Agreed on disagree: "safely" is misleading and I meant it to be along your "nice and fast code", deployable in production. I'm under the impression that
SIOCGSKNS is strange as it returns the network namespace which was originally active when /dev/net/tun was opened. When moving the TAP/TUN later as in my example, the original network namespace would be returned, but the network interface isn't there anymore. The network namespace handling in tun.c looks slightly odd to me in places, especially when the stored original netns is passed but then ignored...– TheDiveO
Mar 7 at 22:08
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
"SIOCGSKNS ... returns the network namespace which was originally active when /dev/net/tun was opened." that is unfortunately true ;-( wrong call, then.
– mosvy
Mar 7 at 23:30
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504861%2fhow-to-get-the-linux-network-namespace-for-a-tap-tun-device-referenced-in-proc%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Note that there's
ip netns identify $PIDthat should give you the net namespace of$PIDwithout you having to look at nsfs inode numbers (andip netns pids foozto go the other way), but they don't seem to find anything either. Sounds like a kernel bug.– TooTea
Mar 7 at 10:40
@TooTea
ip netns identify $PIDis doing nothing more than taking/proc/$PID/ns/netand then trying to match only against its own list of bind-mounted symbolic network namespace names. Unfortunately, that's most of the time rather pointless as few are using iproute2's bindmount positions. My example is just usingip netns ...to give an easily reproducable example to check the underlying mechanisms, but it's not a typical deployment situation.– TheDiveO
Mar 7 at 14:16