From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 081591384C3 for ; Tue, 15 Jan 2013 22:36:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EF121E062B; Tue, 15 Jan 2013 22:36:52 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by pigeon.gentoo.org (Postfix) with ESMTP id EB156E060D for ; Tue, 15 Jan 2013 22:36:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7185920439 for ; Tue, 15 Jan 2013 22:36:50 +0000 (UTC) Received: from localhost (unknown [64.168.229.50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B219920430; Tue, 15 Jan 2013 22:36:49 +0000 (UTC) Date: Tue, 15 Jan 2013 10:58:56 -0800 From: Greg KH To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] call for testers: udev predictable network interface names Message-ID: <20130115185856.GA22785@kroah.com> References: <20130109221310.GA1749@linux1> <50F51E69.8020507@gentoo.org> <50F560A3.9040503@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F560A3.9040503@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, UNPARSEABLE_RELAY autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP X-Archives-Salt: d0decf10-907f-4ad9-a6d5-d7eb52bf51ea X-Archives-Hash: 12bb41bd0a2d80695a5421e070611898 On Tue, Jan 15, 2013 at 08:58:59AM -0500, Ian Stakenvicius wrote: > On 15/01/13 04:16 AM, Michael Weber wrote: > > Hi, > > > > "This can have serious security implications" [1] > > > > For whom? > > I think the idea there is that a user expects eth0 and eth1 to stay > the same, writes iptables rules on a per-interface basis to control > what they want, then update the kernel or make some other change > (upgraded udev, maybe? :D) which swaps them around and poof, the rules > they thought were correct don't end up protecting them they way they > assumed it would... > > Not saying this is necessarily valid, just saying how I interpreted > their meaning of "serious security implications". Yes, that is true. And it's not udev that could rename the interface (hint, it wouldn't), it's the kernel, it _never_ guarantees the same interface "name" every time you boot. You might just be getting lucky, but really, PCI busses can be enumerated in different ways, USB devices can come and go and initialize sometimes slower one boot from another, and lots of other things can happen. So anyone who relies on network names right now to be deterministic, and you have more than one network device in your system, should seriously reconsider how they are naming their devices, as it will not work if you only rely on the kernel. You might have gotten "lucky" for the past 5 years, but you never know what could happen if you reboot today. Seriously, I've seen it happen all the time. Hope this helps explain things a bit better. greg k-h