qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Shaun Reitan <shaun.reitan@ndchost.com>
Cc: qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Add ability to provide ifname when using netdev bridge or tap helper
Date: Wed, 17 Jan 2018 10:31:48 +0000	[thread overview]
Message-ID: <20180117103148.GE19227@redhat.com> (raw)
In-Reply-To: <20180116231824.27114-1-shaun.reitan@ndchost.com>

On Tue, Jan 16, 2018 at 03:18:24PM -0800, Shaun Reitan wrote:
> This patch replaces the patch I sent yesturday. This one fixes
> a bug in my original code as well as corrects a few styling
> issues. Hopfully this one comes out correct!  Sorry for the
> inconvienece.
>  
> When currently using -netdev bridge or -netdev tap with a helper
> you are unable to set an ifname. This patch adds that ability so
> that you can now specify an ifname.

I really don't think users should be allowed to override the
ifname when using the setuid bridge helper. This allows an
unprivileged users to create tap devices that may confuse the
sysadmin, and/or network mgmt scripts.

eg consider the user asks for a tap device called  eth1. To the
sysadmin the user's tap device now looks like a physical NIC.
This can be even worse if the host does physical NIC hotplug,
or uses SRIOV. eg consider the host as eth0 -> eth7 for SRIOV
NICs, and eth3 is given to a guest. Now a user uses the setuid
helper to ask for a TAP called eth3. When the SRIOV device is
later released by the guest it will end up called eth8, as the
TAP device occupies eth3. In bad cases this could even cause
the host mgmt layer to configure bogus addresses on the eth3
TAP device instead of the SRIOV device.

If we want to allow ifname to be set via the setuid helper, then IMHO,
the config file for the helper *must* whitelist the various permitted
naming patterns.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  parent reply	other threads:[~2018-01-17 10:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16 23:18 [Qemu-devel] [PATCH] Add ability to provide ifname when using netdev bridge or tap helper Shaun Reitan
2018-01-17  3:35 ` Jason Wang
2018-01-17 10:31 ` Daniel P. Berrange [this message]
2018-01-17 10:39   ` Paolo Bonzini
2018-01-17 13:28     ` Philippe Mathieu-Daudé
2018-01-17 10:53   ` Jason Wang
2018-01-17 10:58     ` Daniel P. Berrange
2018-01-17 15:26 ` Eric Blake
2018-01-17 18:11   ` Shaun Reitan
2018-01-18 11:53     ` Jason Wang
2018-01-18 21:56       ` Shaun Reitan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180117103148.GE19227@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shaun.reitan@ndchost.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).