lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49B13259.9040701@trash.net>
Date:	Fri, 06 Mar 2009 15:25:29 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] macvlan: Support creating macvlans from macvlans

Eric W. Biederman wrote:
> Patrick McHardy <kaber@...sh.net> writes:
> 
>>> So modify macvlan creation to allow automatically forward
>>> a creation of a macvlan on a macvlan to become a creation
>>> of a macvlan on the underlying network device.
>> I'm not sure I understand the constallation, what is the underlying
>> device in this case? A device outside the namespace?
> 
> Yes.
> 
> Typical usage would be:
> 
> eth0 in the initial namespace.
> A macvlan off of eth0 in each child namespace.
> 
> Which works fine until I do things like create a network namespace
> when I am already inside of a network namespace.  A child of a child.
> In which case I have to start rigging up something like a pair of
> veths an bridging or routing to get outside connectivity.
> 
> Or roughly:
> ip link add mv0 link eth0 type macvlan.
> ip link add mv1 link eth0 type macvlan.
> ip link set mv0 netns 1234
> ip link set mv1 netns 6789
> 
> Then later I would find it very handy to do:
> echo $$ -> 1234
> ip link add mv3 link mv0 type macvlan
> ip link set mv3 netns 101112

That makes sense of course. I'm mainly wondering whether a namespace
should be able to directly affect the real device like this. This
might move it to promiscous mode, or affect other performce-relevant
settings. Its also looks like you can steal the MAC address of a
different macvlan device this way and have the packets directed to you
(new devices are added to the beginning of the hash chains, so they
are found first on lookups).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ