Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Ben Taylor]

---- "Kevin F. Quinn" <ml@kevquinn.com> wrote: 
> On Fri, 9 Feb 2007 22:48:51 +0000
> Paul Brook <paul@codesourcery.com> 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] Two quick requests.

[Rob Landley]

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?

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?  (The error 
messages are a bit vague here, because it _thinks_ earlier steps succeeded.)

Thanks.  0.9.0 looks really nice.  Are qops going in next?

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

Re: [Qemu-devel] Two quick requests.

[Paul Brook]

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

Re: [Qemu-devel] Two quick requests.

[Dan Shearer]

On Fri, Feb 09, 2007 at 10:27:08PM +0000, Paul Brook wrote:
> 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.

True but I think Rob wants to prevent the  "accidentally" bit because
that isn't the only bad thing you can do with QEMU as root by accident.
The user's intention can be (more or less) detected with a parameter
like "-force-run-as-root". Since once of QEMU's main points is to avoid
the need for root access I think that's reasonable.

-- 
Dan Shearer
dan@shearer.org

Re: [Qemu-devel] Two quick requests.

[Paul Brook]

On Friday 09 February 2007 22:33, Dan Shearer wrote:
> On Fri, Feb 09, 2007 at 10:27:08PM +0000, Paul Brook wrote:
> > 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.
>
> True but I think Rob wants to prevent the  "accidentally" bit because
> that isn't the only bad thing you can do with QEMU as root by accident.
> The user's intention can be (more or less) detected with a parameter
> like "-force-run-as-root". Since once of QEMU's main points is to avoid
> the need for root access I think that's reasonable.

I've very little sympathy (read: none) for people who "accidentally" break 
things by running them as root.

Paul

CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Fri, 9 Feb 2007 22:48:51 +0000
Paul Brook <paul@codesourcery.com> 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.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Paul Brook]

> 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

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Chris Friedhoff]

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 +0000
Paul Brook <paul@codesourcery.com> 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
chris@friedhoff.org