search for: iff_auto_manag

.... Imagine > creating symlinks between these two namespaces as an analogy. All > userspace visible netdevs today will have both a kernel name and a > userspace visible name, having one (/class/net) referecing the other > (/class/net-kernel) in its own namespace. The newly introduced > IFF_AUTO_MANAGED device will have a kernel name only > (/class/net-kernel). As a result, the existing applications using > /class/net don't break, while we're adding the kernel namespace that > allows IFF_AUTO_MANAGED devices which will not be exposed to userspace > at all. My gut feeling is...

.... Imagine > creating symlinks between these two namespaces as an analogy. All > userspace visible netdevs today will have both a kernel name and a > userspace visible name, having one (/class/net) referecing the other > (/class/net-kernel) in its own namespace. The newly introduced > IFF_AUTO_MANAGED device will have a kernel name only > (/class/net-kernel). As a result, the existing applications using > /class/net don't break, while we're adding the kernel namespace that > allows IFF_AUTO_MANAGED devices which will not be exposed to userspace > at all. My gut feeling is...

...ween these two namespaces as an analogy. All > >> userspace visible netdevs today will have both a kernel name and a > >> userspace visible name, having one (/class/net) referecing the other > >> (/class/net-kernel) in its own namespace. The newly introduced > >> IFF_AUTO_MANAGED device will have a kernel name only > >> (/class/net-kernel). As a result, the existing applications using > >> /class/net don't break, while we're adding the kernel namespace that > >> allows IFF_AUTO_MANAGED devices which will not be exposed to userspace >...

Hi Siwei > I think everyone seems to agree not to fiddle with the ":" prefix, but > rather have a new class of network subsystem under /sys/class thus a > separate device namespace e.g. /sys/class/net-kernel for those > auto-managed lower netdevs is needed. How do you get a device into this new class? I don't know the Linux driver model too well, but to get a device

Hi Siwei > I think everyone seems to agree not to fiddle with the ":" prefix, but > rather have a new class of network subsystem under /sys/class thus a > separate device namespace e.g. /sys/class/net-kernel for those > auto-managed lower netdevs is needed. How do you get a device into this new class? I don't know the Linux driver model too well, but to get a device

...to userspace (/class/net). Imagine creating symlinks between these two namespaces as an analogy. All userspace visible netdevs today will have both a kernel name and a userspace visible name, having one (/class/net) referecing the other (/class/net-kernel) in its own namespace. The newly introduced IFF_AUTO_MANAGED device will have a kernel name only (/class/net-kernel). As a result, the existing applications using /class/net don't break, while we're adding the kernel namespace that allows IFF_AUTO_MANAGED devices which will not be exposed to userspace at all. As this requires changing the internal...

...reating symlinks between these two namespaces as an analogy. All >> userspace visible netdevs today will have both a kernel name and a >> userspace visible name, having one (/class/net) referecing the other >> (/class/net-kernel) in its own namespace. The newly introduced >> IFF_AUTO_MANAGED device will have a kernel name only >> (/class/net-kernel). As a result, the existing applications using >> /class/net don't break, while we're adding the kernel namespace that >> allows IFF_AUTO_MANAGED devices which will not be exposed to userspace >> at all. &gt...

Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern at gmail.com wrote: >On 4/3/18 9:42 AM, Jiri Pirko wrote: >>> >>> There are other use cases that want to hide a device from userspace. I >> >> What usecases do you have in mind? > >As mentioned in a previous response some kernel drivers create control >netdevs. Just as in this case users should not be mucking

...; > The question is if this a security feature then it needs to be more I don't expect the namespace to be a security aspect of feature, but rather a way to make old userspace unmodified to work with a new feature. And, we're going to add API to expose the netdev info for the invisible IFF_AUTO_MANAGED links anyway. We don't need to make it secure and all hidden under the dark to be honest. > robust than just name prefix. Plus it took years to handle network > namespaces everywhere; this kind of flag would start same problems. > > Network namespaces work but have the problem na...