[libvirt] [PATCH 1/3] Attempt to load tun module on tap add error
When attempting to add a tap device, the error message is fairly cryptic as to what really happened. If possible, try to load the tun module and then try again to add the tap device again to improve the user experience. Signed-off-by: Doug Goldstein <cardoe@gentoo.org> --- src/util/bridge.c | 21 +++++++++++++++++++-- 1 files changed, 19 insertions(+), 2 deletions(-) diff --git a/src/util/bridge.c b/src/util/bridge.c index 7d0caae..ca4bcc9 100644 --- a/src/util/bridge.c +++ b/src/util/bridge.c @@ -486,12 +486,29 @@ brAddTap(brControl *ctl, { int fd; struct ifreq ifr; + const char * const argv[] = { "modprobe", "tun", NULL }; + int err, exitstatus = 0; if (!ctl || !ctl->fd || !bridge || !ifname) return EINVAL; - if ((fd = open("/dev/net/tun", O_RDWR)) < 0) - return errno; + if ((fd = open("/dev/net/tun", O_RDWR)) < 0) { + err = errno; + + /* If the tun device was non-existent, lets try to load the module */ + if (err == ENOENT) { + if (virRun(argv, &exitstatus) < 0) { + return ENOENT; + } + + /* Now lets try to open the tun device again */ + if ((fd = open("/dev/net/tun", O_RDWR)) < 0) { + return errno; + } + } else { + return err; + } + } memset(&ifr, 0, sizeof(ifr)); -- 1.7.2
On 08/05/10 - 02:12:36PM, Doug Goldstein wrote:
When attempting to add a tap device, the error message is fairly cryptic as to what really happened. If possible, try to load the tun module and then try again to add the tap device again to improve the user experience.
Signed-off-by: Doug Goldstein <cardoe@gentoo.org> --- src/util/bridge.c | 21 +++++++++++++++++++-- 1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/util/bridge.c b/src/util/bridge.c index 7d0caae..ca4bcc9 100644 --- a/src/util/bridge.c +++ b/src/util/bridge.c @@ -486,12 +486,29 @@ brAddTap(brControl *ctl, { int fd; struct ifreq ifr; + const char * const argv[] = { "modprobe", "tun", NULL }; + int err, exitstatus = 0;
Hm, I can't say I like this. Libvirt really shouldn't be in the business of loading kernel modules (I know, we actually do this in the pci passthrough code, but I don't think we should). Besides being pretty gross, this will cause havoc with security policies (like SELinux): you'll need to make the security module allow libvirtd the ability to modprobe any module, which means that any flaw in libvirtd turns into a possible system-wide compromise. -- Chris Lalancette
On Thu, Aug 05, 2010 at 03:21:34PM -0400, Chris Lalancette wrote:
On 08/05/10 - 02:12:36PM, Doug Goldstein wrote:
When attempting to add a tap device, the error message is fairly cryptic as to what really happened. If possible, try to load the tun module and then try again to add the tap device again to improve the user experience.
Signed-off-by: Doug Goldstein <cardoe@gentoo.org> --- src/util/bridge.c | 21 +++++++++++++++++++-- 1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/util/bridge.c b/src/util/bridge.c index 7d0caae..ca4bcc9 100644 --- a/src/util/bridge.c +++ b/src/util/bridge.c @@ -486,12 +486,29 @@ brAddTap(brControl *ctl, { int fd; struct ifreq ifr; + const char * const argv[] = { "modprobe", "tun", NULL }; + int err, exitstatus = 0;
Hm, I can't say I like this. Libvirt really shouldn't be in the business of loading kernel modules (I know, we actually do this in the pci passthrough code, but I don't think we should). Besides being pretty gross, this will cause havoc with security policies (like SELinux): you'll need to make the security module allow libvirtd the ability to modprobe any module, which means that any flaw in libvirtd turns into a possible system-wide compromise.
Agreed, loading kernel modules in this way isn't desirable. If tun needs to be loaded, it should be done before libvirt even starts, eg by initscripts or some other auto-loading mechanism. FYI, even though PCI passthrough code has support for modprobe pciback, this never runs on Fedora since pciback is a standard built-in module, hence not a security problem there. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Chris Lalancette -
Daniel P. Berrange -
Doug Goldstein