Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)
Have a look here with links and a description: http://www.friedhoff.org/fscaps.html http://www.friedhoff.org/fscaps.html#Qemu Serges patch is in the mm tree. Chris On Sat, 10 Feb 2007 15:11:00 + Paul Brook [EMAIL PROTECTED] wrote: Is there any way around this? I expected to be able to configure capabilities for executables in the filesystem, but it appears there are serious problems with that concept so the kernel doesn't support it. Use tunctl to create the device. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Chris Friedhoff [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Two quick requests.
If you really want to do this, do it properly. Make it an error to use a ro image if the user [implicitly] requests rw access. If there's no middle ground between silently misbehave and refuse to start if anything _might_ be wrong, then why does current qemu warn about the 1024 hz thing? Even at 1024Hz qemu still misbehaves, especially on heavily loaded hosts. 1024Hz is sufficient for most common operating systems most of the time, but many will run happily without it. e.g. many linux kernels only need 100 or 250Hz. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Two quick requests.
Rob Landley schrieb: On Friday 09 February 2007 6:06 pm, Paul Brook wrote: Sure, but there are plenty of other ways to accidentally mess up the permissions of a disk image file. A while back I had to strace qemu to figure out why file modifications were vanishing after rebooting the VM; the culprit turned out to be an unrelated script that had set the image file's mode to 444. If you really want to do this, do it properly. Make it an error to use a ro image if the user [implicitly] requests rw access. If there's no middle ground between silently misbehave and refuse to start if anything _might_ be wrong, then why does current qemu warn about the 1024 hz thing? Just curious. Refusing to start would have saved me a day's debugging time, just like the warning would have... Rob I think adding a simple (suppressable) warning on startup would be sufficient in case of a ro image. Jan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)
Kevin F. Quinn [EMAIL PROTECTED] wrote: On Fri, 9 Feb 2007 22:48:51 + Paul Brook [EMAIL PROTECTED] wrote: I've very little sympathy (read: none) for people who accidentally break things by running them as root. On a related note, I've been running qemu(-system 0.8.2) as root recently as a hopefully temporary measure so that it can setup the network interfaces. Recent linux kernels require CAP_NET_ADMIN for the tun network configuration that qemu does (specifically the TUNSETIFF ioctl), and the only way to get the capability is to start the process as root. Other capabilities could be dropped; as indeed could CAP_NET_ADMIN once the network configuration is done, but that means modifications to qemu itself to release the capabilities, and would still leave qemu as a suid-root binary, which it would be nicer to avoid. Is there any way around this? I expected to be able to configure capabilities for executables in the filesystem, but it appears there are serious problems with that concept so the kernel doesn't support it. I just dealt with that. I got a patch for tap for Solaris and I have a setuid script that creates the tap and uses the /etc/qemu-ifup script to configure the interface, then calls a script with the file descriptor of the tap interface to a script which then invokes qemu with the right parameteres. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)
Is there any way around this? I expected to be able to configure capabilities for executables in the filesystem, but it appears there are serious problems with that concept so the kernel doesn't support it. Use tunctl to create the device. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Two quick requests.
On Fri, Feb 09, 2007 at 11:06:24PM +, Paul Brook wrote: Sure, but there are plenty of other ways to accidentally mess up the permissions of a disk image file. A while back I had to strace qemu to figure out why file modifications were vanishing after rebooting the VM; the culprit turned out to be an unrelated script that had set the image file's mode to 444. If you really want to do this, do it properly. Make it an error to use a ro image if the user [implicitly] requests rw access. But if you do this please be sure not to complain about rw COW images based on readonly ones... -- Daniel Jacobowitz CodeSourcery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Two quick requests.
On Friday 09 February 2007 22:19, Rob Landley wrote: 1) When you accidentally run qemu as root, could it NOT try to go into a full-screen display by default resulting in a corrupted display you can't break out of and have to power cycle the machine? This is a feature of your SDL libraries. They're probably trying to use console framebuffer output. Complain to whoever supplied your SDL libraries. 2) After said reboot, when you're sanely running qemu as a normal user but using the hda image file you made as root, if a hard drive image isn't writeable, could it warn or something, rather than having the ubuntu install mysteriously fail halfway through when it finds itself unable to mount /dev/hda1 after it thinks it just partitioned the drive? I think this is also a feature. Previous versions would refuse to use readonly images at all. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
