From user-land up to the stack
In the previous story we seen what the network stack really represent and how is built up in the kernel , the interesting question would be to see how does this work from user-land.
The real question would be:
How is it that i see only the namespace’s interfaces when i do ifconfig from within a namespace???
Let me illustrate it
Root Namespace
(We get the loopback to eths and a veth pair)
From “blue” namespace:
So this all look very good , so lets drill into it.
- We want to intercept the call that actually returns this info (strace)
Ok so strace tells you that this is reading info from /proc (we kind of knew this , or supposed it)
2. Let’s look in the kernel for the proc implementation
I ended up finding interesting stuff in fs/proc/proc_net.c
I’ve highlighted the important stuff in orange, let’s go by parts:
- The init function takes a struct net , this is the whole network stack of a namespace (devs , routes, etc) .
- netd is allocated
- netd seems to be a struct so some attributes ate filled up (data , namelen(3 ==net ) etc
- we set the attribute proc_net on stuct net to be netd
This suggest that the actual network stack implementation (struct net ) **** holds the information the proc fs entry?
let’s verify this in struct net , include/net/net_namespace.h
There it is , so when a network stack is allocated for a namespace the dentry for the proc fs lies inside the struct net itself , hence it can display information only related to its own struct net (namespace).
Next time let’s look into those structs and who populates the “dev” leaf inside proc/net.
Thanks!