On Thu, 2007-03-01 at 08:25 +0200, Leonard Norrgard wrote: > Thanks for the detailed bug report, although I don't think this really > qualifies as a bug.
Only to the extent that users trying to run kvm as non-root will be in for some fun web searching to figure this out. (It could be argued that all programs require this to some extent, I was just hoping to make the process easier) > | I'm using a kernel >=2.6.18 and am having problems with tun/tap and QEMU > | > http://www.kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-2511814cb92c14dbe1480089c04f83c281117a86 Thanks for pointing that out, I completely overlooked it. Guess I was a bit too quick to jump to search... > I haven't got a plan for what to do about this yet. It seems that > giving the qemu/kvm binary cap_net_admin re-opens the hole that the > kernel patch fixed to begin with. On the other hand, requiring kvm > users to have sudo access is just as bad. Is there any way to give users in the kvm group cap_net_admin capability (when running kvm)? I suppose making the binary only group and user executable and setting cap_net_admin would do it. Are there any typical use cases where people using the binary are not in the kvm group (which would require changing permissions on /dev/kvm AFAIK). > Perhaps on '/etc/init.d/kvm start', automatically create one or more > interfaces for each user in the kvm group? > > #!/bin/sh > for user in `grep ^kvm: /etc/group | cut -d : -f 4 | tr , ' '`; do > tunctl -u ${user} -t tap-${user}0 > #tunctl -u ${user} -t tap-${user}1 > #tunctl -u ${user} -t tap-${user}2 > done Sure. Would kvm then attempt to use these interfaces automatically or would the user be encouraged to pass them as iface= arguments? Seems like it might be a little bit excessive on systems with many users in the kvm group, but it would probably get the job done. > This is the kind of task that virt-manager [1] may be more suited to > handle at some level. Yeah, probably true. > Thanks for the perror() suggestion. Sure. While you are at it, you might want to add one to the ioctl() at qemu/vl.c:1001 on /dev/rtc (or even check for an inappropriate ioctl errno) since HPET systems do not support the RTC_IRQP_SET ioctl[1]. 1. https://www.x86-64.org/pipermail/bugs/2003-December/000828.html -- Cheers, | [EMAIL PROTECTED] | [EMAIL PROTECTED] Kevin | http://kevinlocke.name | kevinoid on freenode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
