Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Fri, Sep 03, 2010 at 02:50:00PM -0600, Eric Blake wrote: On 09/03/2010 02:38 PM, Soren Hansen wrote: NACK, I don't think we should be changing this. If the user is unprivileged, it should always default to the unprivileged libvirtd, regardless of whether they are also authorized to connect to the privileged libvirtd (via socket permissions or policykit, or kerberos). If the unprivileged user still wants the privileged libvirtd, they should given an explicit URI. Hm... I didn't think this was going to be controversial :) Maybe a less-controversial patch would be changing configure.ac to add a configure option for the default URI string for non-privileged users? Right now, the default is hard-coded to qemu:///session, but by letting it be a configure choice, then it would be up to the end user (or distro) whether to risk the default of qemu:///system as well as exposing the socket as writable. There is no compile time concept of default URI to make configurable. If no URI is found, libvirt probes each hypervisor driver in turn. As an end user though, you can edit $HOME/.bashrc and set the env variable LIBVIRT_DEFAULT_URI to ensure a URI is always found before it gets the probing logic. Regards, 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Fri, Sep 03, 2010 at 11:04:21PM +0200, Soren Hansen wrote:
On 03-09-2010 15:59, Daniel Veillard wrote:
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index a945710..17e6ead 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -1086,7 +1086,7 @@ remoteOpen (virConnectPtr conn,
if (!conn-uri) {
DEBUG0(Auto-probe remote URI);
#ifndef __sun
-if (getuid() 0) {
+if (access(LIBVIRTD_PRIV_UNIX_SOCKET, W_OK)) {
DEBUG0(Auto-spawn user daemon instance);
rflags |= VIR_DRV_OPEN_REMOTE_USER;
if (!autostart ||
Hum, that sounds like a change of semantic.
Depends. I think of the (getuid() 0) as a check for whether you can
access the privileged UNIX socket that simply doesn't take into account
that users other than root may have been given this privilege by way of
membership of the group owning the socket.
Before as non root you would span a local daemon, now you use the system
one. I'm not saying it's a bad thing in most cases but it's a serious
change, and we try to avoid those in general.
As I suggested in another e-mail a short while ago in this thread, I'm
making this change to maintain the status quo in Ubuntu. We already do
this in virsh and virt-viewer and something very, very similar in
virt-manager. Someone recently dropped the virt-viewer patch by mistake,
and I decided to make the change directly in libvirt to not change how
libvirt has behaved for us in the past couple of years, so I can
certainly relate to your desire to not change the behaviour.
Personally, at least, I find this behaviour much more pleasant. On all
my servers, I just grant whoever needs to be able to deal with the VM's
on it access to the socket (by adding them to the libvirtd group), and
that's it. I don't need to instruct them to set per-application
environment variables or whatever.
Generally, I use libvirt on two classes of machine: Workstations/laptops
(where I'm functionally the only user), or on servers whose job is to
run virtual machines and nothing else.
In the former case, obviously I want to use the systemwide libvirtd to
get access to all the fancy networking things. I have absolutely no
motivation to use qemu:///session on there anymore.
Our goal is to improve qemu://session's networking such that this isn't
a reason to use qemu://system anymore. Enabing use of qemu://session
is key to solving a number of important security problems, not least
that a user should be able to just keep the disk iso images in their
home directory and not have to worry about their ownership/permissions.
In addition by running VMs directly under the user's session things
like pulseaudio, SDL can directly access the X GNOME sessions without
further special config.
In the latter case, only people who are supposed to manage the virtual
machines will have access to the server, and IMO they have no business
running stuff under qemu:///session on that box.
This is ignoring two important use cases which are common in the
corporate world. Shared development servers where many users are
on one server, and personal workstations where the users are not
allowed to have root.
The thing about heuristics is that they're never correct for everyone.
Your patch is making it more correct for one group of people, and less
correct for a different group of people. Further making a significant
functional change to libvirt that will break things for people that are
relying on the existing behaviour.
If someone wants to save typing they need merely set LIBVIRT_CONNECT_URI
to whatever they want and thus avoid the default connection logic completely.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. Enabing use of qemu://session is key to solving a number of important security problems, not least that a user should be able to just keep the disk iso images in their home directory and not have to worry about their ownership/permissions. True. In addition by running VMs directly under the user's session things like pulseaudio, SDL can directly access the X GNOME sessions without further special config. I was under the impression that currently targeted solution to at least the audio problem was tunelling through VNC? This is ignoring two important use cases which are common in the corporate world. Shared development servers where many users are on one server, and personal workstations where the users are not allowed to have root. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. The thing about heuristics is that they're never correct for everyone. Your patch is making it more correct for one group of people, and less correct for a different group of people. Further making a significant functional change to libvirt that will break things for people that are relying on the existing behaviour. I understand the difficulty of heuristics. That's exactly why I think this discussion is useful: It seeks to determine the accuracy of the current heuristic, which I claim is inaccurate in all but extraordinary cases. If someone wants to save typing they need merely set LIBVIRT_CONNECT_URI to whatever they want and thus avoid the default connection logic completely. As you point out to Eric elsewhere in this thread, this is about adjusting the behaviour of the heuristic, not about just providing a default URI. I admit, though, that I did not know of the environment variable to do this, which is called LIBVIRT_DEFAULT_URI, by the way :) -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. No, we won't change access to the system instance, the policy for that is already configurable per-host by admins if they so desire. It is more a case of making virt-manager use the qemu:///session uri by default, rather than a change in libvirtd. In addition by running VMs directly under the user's session things like pulseaudio, SDL can directly access the X GNOME sessions without further special config. I was under the impression that currently targeted solution to at least the audio problem was tunelling through VNC? Yep, that is another piece of work - they're not mutually exclusive, since the audio-over-VNC functionality is useful for remote access across the network, as well as local system access. This is ignoring two important use cases which are common in the corporate world. Shared development servers where many users are on one server, and personal workstations where the users are not allowed to have root. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. You are equating access to the UNIX socket, with authorization to the unix socket. With PolicyKit auth enabled by default, the UNIX socket is mode 0777 at all times, but this does not imply that all users are able to use it. They can connect, but if PolicyKit denies them, their connection will be dropped by the server. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] esx: Fall back to path as key when QueryVirtualDiskUuid isn't available
On Sat, Sep 04, 2010 at 01:36:08AM +0200, Matthias Bolte wrote: QueryVirtualDiskUuid is only available on an ESX(i) server. vCenter returns an NotImplemented fault and a GSX server is missing the VirtualDiskManager completely. Therefore only use QueryVirtualDiskUuid with an ESX(i) server and fall back to path as storage volume key for vCenter and GSX server. ACK, doing the dynamic allocation of the UUId is a good thing too Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] mingw: match recent changes in spec file
On Fri, Sep 03, 2010 at 02:12:47PM -0600, Eric Blake wrote: These changes allow './autobuild.sh' to complete again, when a full mingw cross-compilation is available on Fedora. * libvirt.spec.in (%file): List new installed files. * configure.ac (with_init_script): Assume default of none when cross-compiling. Looks fine to me, ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On 06-09-2010 12:24, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. No, we won't change access to the system instance, the policy for that is already configurable per-host by admins if they so desire. Yes, that's what I meant. If qemu:///session turns useful enough, admins won't give users access to the privileged UNIX socket. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. You are equating access to the UNIX socket, with authorization to the unix socket. Indeed I am. With PolicyKit auth enabled by default, the UNIX socket is mode 0777 at all times, but this does not imply that all users are able to use it. They can connect, but if PolicyKit denies them, their connection will be dropped by the server. Fascinating. I had no idea. That's a very convincing argument :) What if I could come up with a check for whether the user would be authorized to access the socket? Like including a auth_unix_rw == none condition in the check? Would that change your view at all? -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote: On 06-09-2010 12:24, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. No, we won't change access to the system instance, the policy for that is already configurable per-host by admins if they so desire. Yes, that's what I meant. If qemu:///session turns useful enough, admins won't give users access to the privileged UNIX socket. Or they'll leave the permissions 0777 and simply change the policykit rule to deny access, or they'll not change anything, and simply not tell the user the root password, which is what's required to be entered with policykit to access qemu:///system. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. You are equating access to the UNIX socket, with authorization to the unix socket. Indeed I am. Therein lies the flaw in this approach. With PolicyKit auth enabled by default, the UNIX socket is mode 0777 at all times, but this does not imply that all users are able to use it. They can connect, but if PolicyKit denies them, their connection will be dropped by the server. Fascinating. I had no idea. That's a very convincing argument :) What if I could come up with a check for whether the user would be authorized to access the socket? Like including a auth_unix_rw == none condition in the check? Would that change your view at all? PolicyKit is just one example I happened to pick, the same logic applies to any of the other authentication/authorization methods that libvirtd applies. Any check based on socket permissions is fundamentally flawed, even with auth_unix_rw=none (which you can't check because a non-root user can't read /etc/libvirt/libvirtd.conf), when we add role based access control, you may be able to connect to the 'rw' socket, but have no more privileges than on the 'ro' socket. Regards, 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] how to Create virtual machine
Hi, I am working on a virtualization project that involves setting up virtual appliances to implement the same, which tool is required to 1) create virtual appliances 2) deploy virtual appliances 3) manage virtual appliances/virtual machines Could you please guide me with some pointers or resources to get started with the creation of virtual machines? I am little confused with libvirt with Xen and qemu. how does xen or qemu related with libvirt ? Thank you. Saravanan Sundaramoorthy Red Hat Certified Engineer http://www.google.com/profiles/dearsaravanan#about +91 99404 32545 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Need help, how can I access to qemu-monitor with libvirt 0.8.1
Hi, all I encounter this problem when I try to send NMI to guest. I don't know how. I think if I can access to the qemu-monitor, I can just do this command in the qemu-monitor: nmi cpu#. But I don't know how to access to qemu-monitor, I think I can get help here. I noticed that the guest is started by libvirt with these parameters: -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/vm~laijs.monitor,server,nowait \ -mon chardev=monitor,mode=control So I wrote a simple program and tried to access qemu-monitor by accessing the socket /var/lib/libvirt/qemu/vm~laijs.monitor. It failed, because I don't know how to send commands with mode=control, I don't know the protocol for exchanging data with this file. (If I start guest with the same parameters as libvirt but using mode=readline, I successfully sent commands to qemu-monitor by my simple program, I just send text commands) I noticed that libvirt 0.8.3 supports remote protocol and arbitrary qemu commands, but I did not found any document, how can I use it? Thanks, Lai, (I'm not in this email-list:libvir-list@redhat.com, please ensure my email address in your cc-list when you reply, thanks) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] XP install: where to ask questions?
On Fedora FC14 I'm trying to install XP under KVM/qemu. It works with VBOx. On FC14, kvm/qemu I've used F5 to select i486 C-step, but after the formatting step, I get a message that VNC no longer connects with the hypervisor. Googled, but no help. Is this the list to discuss this sort of issue? If not, where? sean -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Need help, how can I access to qemu-monitor with libvirt 0.8.1
On 08/31/2010 09:55 PM, Eric Blake wrote: On 08/31/2010 03:41 AM, Lai Jiangshan wrote: Hi, all I encounter this problem when I try to send NMI to guest. I don't know how. I think if I can access to the qemu-monitor, I can just do this command in the qemu-monitor: nmicpu#. But I don't know how to access to qemu-monitor, I think I can get help here. The only way to do this with libvirt 0.8.1 is to write a wrapper script which adds arguments and invokes the real qemu, then point libvirt to the location of the wrapper instead of the real qemu. Not the most trivial task. Does this way breaks libvirt? libvirt also uses the qemu-monitor If I change the arguments for monitor, I think it will break libvirt. what I want to do is sending some commands to qemu-monitor, I don't want to change existed things. I noticed that libvirt 0.8.3 supports remote protocol and arbitrary qemu commands, but I did not found any document, how can I use it? That's different than the 0.8.1 of your subject line. Yes, 0.8.3 makes it easier to add additional arbitrary arguments to the qemu command line via your XML file. The list archives has several examples of this; most recently: https://www.redhat.com/archives/libvir-list/2010-August/msg00589.html Another question, how can I use the remote protocol(arbitrary qemu monitor commands)? Thanks, Lai. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote: On 06-09-2010 12:24, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. No, we won't change access to the system instance, the policy for that is already configurable per-host by admins if they so desire. Yes, that's what I meant. If qemu:///session turns useful enough, admins won't give users access to the privileged UNIX socket. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. You are equating access to the UNIX socket, with authorization to the unix socket. Indeed I am. With PolicyKit auth enabled by default, the UNIX socket is mode 0777 at all times, but this does not imply that all users are able to use it. They can connect, but if PolicyKit denies them, their connection will be dropped by the server. Fascinating. I had no idea. That's a very convincing argument :) What if I could come up with a check for whether the user would be authorized to access the socket? Like including a auth_unix_rw == none condition in the check? Would that change your view at all? Speaking personally and as a user here, I think qemu://session is a good thing, I think the process of giving users elevated permissions to use qemu+KVM has been a bad thing for a while now and any attempts at correcting this behaviour is a positive step. If someone is in an environment where they need to manage the system qemu instance (i.e. production environments) then I would imagine that they would be aware that they need to connect 'somewhere else'. If the environment variable suggested before already exists (sorry couldn't tell) then that is enough to allow those companies to change the default behaviour. My 2 cents. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Mon, Sep 06, 2010 at 10:17:17AM +0100, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore. BTW, some ideas we have for attacking this problem are - Add support to network manager to create TAP devices on behalf of the logged in user. Thus libvirt would talk to NM over dbus and ask it to create a TAP device, which we then pass to QEMU in the normal manner. Thus neither libvirtd or QEMU need higher privileges. This also requires NM to understand bridging setup. - Integrate with VDE as the solution for the 'virtual network' functionality in libvirt. This improves on 'user' networking mode by allowing VMs to talk to each other, out of the box they still have slirp based access to the outside world. It is possible to make VDE use a TAP device for connectivity to the outside world, so either the admin can set one up, or again we can ask network manager todo it, which in this case doesn't require full bridging support - just NAT which NM can already do via its 'connection sharing' feature. - A setuid helper program that libvirtd can use for setting up TAP devices. This is just a crappier version of getting network manager todo it for us. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On 06-09-2010 13:22, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote: On 06-09-2010 12:24, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. No, we won't change access to the system instance, the policy for that is already configurable per-host by admins if they so desire. Yes, that's what I meant. If qemu:///session turns useful enough, admins won't give users access to the privileged UNIX socket. Or they'll leave the permissions 0777 and simply change the policykit rule to deny access, or they'll not change anything, and simply not tell the user the root password, which is what's required to be entered with policykit to access qemu:///system. I understand. I wrote the above under the (false) assumption that having write access to the UNIX socket implied having privileges to the system's libvirtd. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. You are equating access to the UNIX socket, with authorization to the unix socket. Indeed I am. Therein lies the flaw in this approach. Yes, I learned that a few lines further down. :) With PolicyKit auth enabled by default, the UNIX socket is mode 0777 at all times, but this does not imply that all users are able to use it. They can connect, but if PolicyKit denies them, their connection will be dropped by the server. Fascinating. I had no idea. That's a very convincing argument :) What if I could come up with a check for whether the user would be authorized to access the socket? Like including a auth_unix_rw == none condition in the check? Would that change your view at all? PolicyKit is just one example I happened to pick, auth_unix_rw == none was also just an example. the same logic applies to any of the other authentication/authorization methods that libvirtd applies. Of course. Any check based on socket permissions is fundamentally flawed, I feel the same way about one that is based on uid, to be honest. even with auth_unix_rw=none (which you can't check because a non-root user can't read /etc/libvirt/libvirtd.conf), On Ubuntu, /etc/libvirt/libvirtd.conf is mode 0644? Should I be worried about that? A quick glance in there doesn't reveal anything that I'm uncomfortable disclosing. when we add role based access control, you may be able to connect to the 'rw' socket, but have no more privileges than on the 'ro' socket. In that particular case, I could also check for whether RBAC was enabled, but that's really beside the point right now. My question was a general one: Assuming I can determine that a given user is authorized to manage the systemwide libvirtd, would you agree that that is the one they're most likely to want to access? I simply cannot think up a realistic example use case where someone has this privilege, but actually wants to access qemu:///session. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On Mon, Sep 06, 2010 at 02:03:08PM +0200, Soren Hansen wrote: On 06-09-2010 13:22, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote: On 06-09-2010 12:24, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: On 06-09-2010 11:17, Daniel P. Berrange wrote: Our goal is to improve qemu://session's networking such that this isn't a reason to use qemu://system anymore Fair enough, but when that happens, I'm supposing people won't have access to the system-wide UNIX socket anymore. No, we won't change access to the system instance, the policy for that is already configurable per-host by admins if they so desire. Yes, that's what I meant. If qemu:///session turns useful enough, admins won't give users access to the privileged UNIX socket. Or they'll leave the permissions 0777 and simply change the policykit rule to deny access, or they'll not change anything, and simply not tell the user the root password, which is what's required to be entered with policykit to access qemu:///system. I understand. I wrote the above under the (false) assumption that having write access to the UNIX socket implied having privileges to the system's libvirtd. I disagree. In both of those cases, I'd be surprised if people were able to access the privileged libvirtd socket. In the former case, if people generally had access to the systemwide libvirtd instance, I'd assume that was because that was the one they were supposed to use for their shared development stuff. In the latter case, with that sort of access, I could have full root shell access within minutes, so that'd be a pretty big security fail. You are equating access to the UNIX socket, with authorization to the unix socket. Indeed I am. Therein lies the flaw in this approach. Yes, I learned that a few lines further down. :) With PolicyKit auth enabled by default, the UNIX socket is mode 0777 at all times, but this does not imply that all users are able to use it. They can connect, but if PolicyKit denies them, their connection will be dropped by the server. Fascinating. I had no idea. That's a very convincing argument :) What if I could come up with a check for whether the user would be authorized to access the socket? Like including a auth_unix_rw == none condition in the check? Would that change your view at all? PolicyKit is just one example I happened to pick, auth_unix_rw == none was also just an example. the same logic applies to any of the other authentication/authorization methods that libvirtd applies. Of course. Any check based on socket permissions is fundamentally flawed, I feel the same way about one that is based on uid, to be honest. even with auth_unix_rw=none (which you can't check because a non-root user can't read /etc/libvirt/libvirtd.conf), On Ubuntu, /etc/libvirt/libvirtd.conf is mode 0644? Should I be worried about that? A quick glance in there doesn't reveal anything that I'm uncomfortable disclosing. The /etc/libvirt directory itself should be 0700 though, since various files under that location include passwords (qemu.conf, secrets/*, qemu/*xml, lxc/*xml, uml/*xml). We don't currently have any passwords in libvirtd.conf itself, but its certainly possible this might change in the future. While it is possible to rely on getting each individual file there to have correct permissions, IMHO it is safer to make the /etc/libvirt directory 0700 when we add role based access control, you may be able to connect to the 'rw' socket, but have no more privileges than on the 'ro' socket. In that particular case, I could also check for whether RBAC was enabled, but that's really beside the point right now. My question was a general one: Assuming I can determine that a given user is authorized to manage the systemwide libvirtd, would you agree that that is the one they're most likely to want to access? I simply cannot think up a realistic example use case where someone has this privilege, but actually wants to access qemu:///session. No, I don't agree. I already mentioned the reasons why it is desirable to run within the user session - SDL, audio, disk permissions, and to add another one gnome-keyring integration for qcow2 passwords which is a future feature we'd like for the secrets driver. IMHO if we are to get better integration into the user's desktop experiance, then having both libvirtd the VMs running in the user's context, rather than a separate context is key. Regards, 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 :| -- libvir-list mailing list
Re: [libvirt] [PATCH] Default to qemu:///system if accessible
On 06-09-2010 14:18, Daniel P. Berrange wrote: On Ubuntu, /etc/libvirt/libvirtd.conf is mode 0644? Should I be worried about that? A quick glance in there doesn't reveal anything that I'm uncomfortable disclosing. The /etc/libvirt directory itself should be 0700 though, Nope, it's 0755. :( I'll look into getting that fixed. since various files under that location include passwords (qemu.conf, secrets/*, qemu/*xml, lxc/*xml, uml/*xml). We don't currently have any passwords in libvirtd.conf itself, but its certainly possible this might change in the future. While it is possible to rely on getting each individual file there to have correct permissions, IMHO it is safer to make the /etc/libvirt directory 0700 Makes sense. Thanks for pointing this out. I've never used passwords in any of these files myself, so I never really gave it much thought :( Assuming I can determine that a given user is authorized to manage the systemwide libvirtd, would you agree that that is the one they're most likely to want to access? I simply cannot think up a realistic example use case where someone has this privilege, but actually wants to access qemu:///session. No, I don't agree. I already mentioned the reasons why it is desirable to run within the user session - SDL, audio, disk permissions, and to add another one gnome-keyring integration for qcow2 passwords which is a future feature we'd like for the secrets driver. IMHO if we are to get better integration into the user's desktop experiance, then having both libvirtd the VMs running in the user's context, rather than a separate context is key. Yes, of course, when qemu:///session gets this smart and cool you will want to access qemu:///session by default. At /exactly/ the same time, the motivation for setting yourself up with access to qemu:///system disappears. When that motivation is gone, any admin worth his salt will immediately revoke said access (in the shared scenario) (since it's a gaping security hole) and voilà, libvirt will go back to using qemu:///session by default. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virt-top version bump in EPEL5
On Mon, Sep 06, 2010 at 05:46:03PM +0200, Wolfram Schlich wrote: * Richard W.M. Jones rjo...@redhat.com [2010-09-06 17:23]: On Mon, Sep 06, 2010 at 05:06:55PM +0200, Wolfram Schlich wrote: We are experiencing a problem with virt-top on our RHEL5 virthosts. On a heavily loaded virthost, virt-top is damn slow -- it takes 4-5s to update and imposes a noticeable load on the dom0 as well (xenstored shows up in top eating all CPU for some seconds). xentop seems to impose *much* less load on the dom0. Is there something I can do about it? Another problem: 0.3.3.1 shows RDRQ/WRRQ/RXBY/TXBY after some seconds whereas 1.0.4 does not...? I bet both of these will be libvirt issues. Try running: virsh list --all Takes around 2-4s depending on dom0 load. CC-ing to libvir-list. There may be a better way now for virt-top to get the list of domains, but if 'virsh list --all' is also slow, then it's probably a generic libvirt problem. virsh domblkstat DomainName hda s/hda/xvda/ I guess :) This one is quite fast, below 0.2s. virsh domifstat DomainName vnet0 This takes around 0.1s most of the time, but sometimes around 1.0s. etc. If those commands (done in a suitable loop) also cause load on the dom0, and if domblkstat/domifstat don't show stats, then it's down to libvirt. virt-top is a simple little program that just exercises those libvirt APIs ... Hmm :/ So I guess we're better off with xentop... We should be able to have performance very close to xentop. After all, libvirt makes exactly the same direct hypervisor calls. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virt-top version bump in EPEL5
* Richard W.M. Jones rjo...@redhat.com [2010-09-06 17:59]:
On Mon, Sep 06, 2010 at 05:46:03PM +0200, Wolfram Schlich wrote:
* Richard W.M. Jones rjo...@redhat.com [2010-09-06 17:23]:
On Mon, Sep 06, 2010 at 05:06:55PM +0200, Wolfram Schlich wrote:
We are experiencing a problem with virt-top on our RHEL5 virthosts.
On a heavily loaded virthost, virt-top is damn slow -- it takes 4-5s
to update and imposes a noticeable load on the dom0 as well
(xenstored shows up in top eating all CPU for some seconds).
xentop seems to impose *much* less load on the dom0.
Is there something I can do about it?
Another problem: 0.3.3.1 shows RDRQ/WRRQ/RXBY/TXBY after some seconds
whereas 1.0.4 does not...?
I bet both of these will be libvirt issues.
Try running:
virsh list --all
Takes around 2-4s depending on dom0 load.
CC-ing to libvir-list. There may be a better way now for virt-top to
get the list of domains, but if 'virsh list --all' is also slow, then
it's probably a generic libvirt problem.
virsh domblkstat DomainName hda
s/hda/xvda/ I guess :)
This one is quite fast, below 0.2s.
virsh domifstat DomainName vnet0
This takes around 0.1s most of the time, but sometimes around 1.0s.
etc.
If those commands (done in a suitable loop) also cause load on the
dom0, and if domblkstat/domifstat don't show stats, then it's down to
libvirt.
virt-top is a simple little program that just exercises those libvirt
APIs ...
Hmm :/ So I guess we're better off with xentop...
We should be able to have performance very close to xentop. After
all, libvirt makes exactly the same direct hypervisor calls.
xentop is *magnitudes* faster than virt-top, really.
xm list takes ages whereas xenstore-list /local/domain
is quite fast, also xenstore-list /local/domain \
| while read domid; do \
xenstore-read /local/domain/${domid}/name; done
(to get even the domain's name).
Cheers,
Wolfram
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virt-top version bump in EPEL5
On Mon, Sep 06, 2010 at 04:58:42PM +0100, Richard W.M. Jones wrote: On Mon, Sep 06, 2010 at 05:46:03PM +0200, Wolfram Schlich wrote: * Richard W.M. Jones rjo...@redhat.com [2010-09-06 17:23]: On Mon, Sep 06, 2010 at 05:06:55PM +0200, Wolfram Schlich wrote: We are experiencing a problem with virt-top on our RHEL5 virthosts. On a heavily loaded virthost, virt-top is damn slow -- it takes 4-5s to update and imposes a noticeable load on the dom0 as well (xenstored shows up in top eating all CPU for some seconds). xentop seems to impose *much* less load on the dom0. Is there something I can do about it? Another problem: 0.3.3.1 shows RDRQ/WRRQ/RXBY/TXBY after some seconds whereas 1.0.4 does not...? I bet both of these will be libvirt issues. Try running: virsh list --all Takes around 2-4s depending on dom0 load. CC-ing to libvir-list. There may be a better way now for virt-top to get the list of domains, but if 'virsh list --all' is also slow, then it's probably a generic libvirt problem. virsh domblkstat DomainName hda s/hda/xvda/ I guess :) This one is quite fast, below 0.2s. virsh domifstat DomainName vnet0 This takes around 0.1s most of the time, but sometimes around 1.0s. etc. If those commands (done in a suitable loop) also cause load on the dom0, and if domblkstat/domifstat don't show stats, then it's down to libvirt. virt-top is a simple little program that just exercises those libvirt APIs ... Hmm :/ So I guess we're better off with xentop... We should be able to have performance very close to xentop. After all, libvirt makes exactly the same direct hypervisor calls. It depends on which API calls virt-top makes. The virConnectListDomains goes to XenStore (fast), virDomainLookupByID/UUID go to HV (fast). The possibly bad ones are virConnectDefinedDomains goes to /etc/xen (fast) or XenD (slow) and virDomainLookupByName goes to XenD (slow). virsh list --all is slow because inactive domains requires using those latter two APIs which hit XenD. virt-top/xentop shouldn't care about inactive domains though, since they've obviously no interesting CPU time to report :-) In a perfect world you'd also want to use the lifecycle events, so you only need call ListDomains/ListDefinedDomains once, and then get explicit notifications of new virDomainPtr instances without any need todo a lookup. Regads, 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virt-top version bump in EPEL5
On Mon, Sep 06, 2010 at 07:14:47PM +0100, Richard W.M. Jones wrote: On Mon, Sep 06, 2010 at 06:06:08PM +0100, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 04:58:42PM +0100, Richard W.M. Jones wrote: On Mon, Sep 06, 2010 at 05:46:03PM +0200, Wolfram Schlich wrote: * Richard W.M. Jones rjo...@redhat.com [2010-09-06 17:23]: On Mon, Sep 06, 2010 at 05:06:55PM +0200, Wolfram Schlich wrote: We are experiencing a problem with virt-top on our RHEL5 virthosts. On a heavily loaded virthost, virt-top is damn slow -- it takes 4-5s to update and imposes a noticeable load on the dom0 as well (xenstored shows up in top eating all CPU for some seconds). xentop seems to impose *much* less load on the dom0. Is there something I can do about it? Another problem: 0.3.3.1 shows RDRQ/WRRQ/RXBY/TXBY after some seconds whereas 1.0.4 does not...? I bet both of these will be libvirt issues. Try running: virsh list --all Takes around 2-4s depending on dom0 load. CC-ing to libvir-list. There may be a better way now for virt-top to get the list of domains, but if 'virsh list --all' is also slow, then it's probably a generic libvirt problem. virsh domblkstat DomainName hda s/hda/xvda/ I guess :) This one is quite fast, below 0.2s. virsh domifstat DomainName vnet0 This takes around 0.1s most of the time, but sometimes around 1.0s. etc. If those commands (done in a suitable loop) also cause load on the dom0, and if domblkstat/domifstat don't show stats, then it's down to libvirt. virt-top is a simple little program that just exercises those libvirt APIs ... Hmm :/ So I guess we're better off with xentop... We should be able to have performance very close to xentop. After all, libvirt makes exactly the same direct hypervisor calls. It depends on which API calls virt-top makes. The virConnectListDomains goes to XenStore (fast), virDomainLookupByID/UUID go to HV (fast). The possibly bad ones are virConnectDefinedDomains goes to /etc/xen (fast) or XenD (slow) and virDomainLookupByName goes to XenD (slow). virsh list --all is slow because inactive domains requires using those latter two APIs which hit XenD. virt-top/xentop shouldn't care about inactive domains though, since they've obviously no interesting CPU time to report :-) Unfortunately we do list them :-( In a perfect world you'd also want to use the lifecycle events, so you only need call ListDomains/ListDefinedDomains once, and then get explicit notifications of new virDomainPtr instances without any need todo a lookup. OK, we might need to move to this model. Is it workable now? In RHEL 5? Yes but the caveat is that not all libvirt drivers support events, so you need to keep the polling code too, and detect whether the driver raises a VIR_ERR_NO_SUPPORT error when registering for the lifecycle events. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virt-top version bump in EPEL5
On Mon, Sep 06, 2010 at 07:31:55PM +0100, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 07:14:47PM +0100, Richard W.M. Jones wrote: On Mon, Sep 06, 2010 at 06:06:08PM +0100, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 04:58:42PM +0100, Richard W.M. Jones wrote: On Mon, Sep 06, 2010 at 05:46:03PM +0200, Wolfram Schlich wrote: * Richard W.M. Jones rjo...@redhat.com [2010-09-06 17:23]: On Mon, Sep 06, 2010 at 05:06:55PM +0200, Wolfram Schlich wrote: We are experiencing a problem with virt-top on our RHEL5 virthosts. On a heavily loaded virthost, virt-top is damn slow -- it takes 4-5s to update and imposes a noticeable load on the dom0 as well (xenstored shows up in top eating all CPU for some seconds). xentop seems to impose *much* less load on the dom0. Is there something I can do about it? Another problem: 0.3.3.1 shows RDRQ/WRRQ/RXBY/TXBY after some seconds whereas 1.0.4 does not...? I bet both of these will be libvirt issues. Try running: virsh list --all Takes around 2-4s depending on dom0 load. CC-ing to libvir-list. There may be a better way now for virt-top to get the list of domains, but if 'virsh list --all' is also slow, then it's probably a generic libvirt problem. virsh domblkstat DomainName hda s/hda/xvda/ I guess :) This one is quite fast, below 0.2s. virsh domifstat DomainName vnet0 This takes around 0.1s most of the time, but sometimes around 1.0s. etc. If those commands (done in a suitable loop) also cause load on the dom0, and if domblkstat/domifstat don't show stats, then it's down to libvirt. virt-top is a simple little program that just exercises those libvirt APIs ... Hmm :/ So I guess we're better off with xentop... We should be able to have performance very close to xentop. After all, libvirt makes exactly the same direct hypervisor calls. It depends on which API calls virt-top makes. The virConnectListDomains goes to XenStore (fast), virDomainLookupByID/UUID go to HV (fast). The possibly bad ones are virConnectDefinedDomains goes to /etc/xen (fast) or XenD (slow) and virDomainLookupByName goes to XenD (slow). virsh list --all is slow because inactive domains requires using those latter two APIs which hit XenD. virt-top/xentop shouldn't care about inactive domains though, since they've obviously no interesting CPU time to report :-) Unfortunately we do list them :-( In a perfect world you'd also want to use the lifecycle events, so you only need call ListDomains/ListDefinedDomains once, and then get explicit notifications of new virDomainPtr instances without any need todo a lookup. OK, we might need to move to this model. Is it workable now? In RHEL 5? Yes but the caveat is that not all libvirt drivers support events, so you need to keep the polling code too, and detect whether the driver raises a VIR_ERR_NO_SUPPORT error when registering for the lifecycle events. Thanks Dan. Wolfram, guess you should open a request for this feature at http://bugzilla.redhat.com/ if you want to see this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virt-top version bump in EPEL5
* Richard W.M. Jones rjo...@redhat.com [2010-09-06 21:00]: On Mon, Sep 06, 2010 at 07:31:55PM +0100, Daniel P. Berrange wrote: On Mon, Sep 06, 2010 at 07:14:47PM +0100, Richard W.M. Jones wrote: On Mon, Sep 06, 2010 at 06:06:08PM +0100, Daniel P. Berrange wrote: In a perfect world you'd also want to use the lifecycle events, so you only need call ListDomains/ListDefinedDomains once, and then get explicit notifications of new virDomainPtr instances without any need todo a lookup. OK, we might need to move to this model. Is it workable now? In RHEL 5? Yes but the caveat is that not all libvirt drivers support events, so you need to keep the polling code too, and detect whether the driver raises a VIR_ERR_NO_SUPPORT error when registering for the lifecycle events. Thanks Dan. Wolfram, guess you should open a request for this feature at http://bugzilla.redhat.com/ if you want to see this. Thanks, I will probably push it to our TAM :) Cheers, Wolfram -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
