Re: inability to open local read-only connection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 12, 2010 at 06:38:27AM -0500, Tavares, John wrote:
> Hi Daniel,
> 
> Sorry it took so long to back to this.  I just recently ran into the
> same problem on RHEL 5.5 where I am running into problems using the 
> root owned setuid executable to get domain information.  Basically 
> all that I needed to do to show this was to modify the example 
> program dominfo/info1.c that ships with the libvirt source and added 
> a function that attempts to get any information about that domain.  
> In this case, I chose the virDomainGetSchedulerType() function.  Here
> is the output of 3 separate runs, the first will be as a non-root user, 
> the second is from root and the last is from the same executable but 
> just root owned setuid and run as a normal user:

I've figured out what is going on here. Originally libvirt provided
a setuid proxy for accessing the Xen driver as non-root. This is
/usr/libexec/libvirt_proxy. This only supports a small sub-set of
API calls and is only for the Xen hypervisor. Later we added a
general purpose daemon (/usr/sbin/libvirtd) that runs as root and
works for all APIs and all hypervisors. This daemon replaces the
setuid proxy, but for reasons of backwards compatability in RHEL5
the proxy is still the default for Xen. The virDomainGetSchedulerType()
API is an example of one that is supported by libvirtd, but not by
the Xen proxy. To force use of the libvirtd, give it an explicit
URI,  xen+unix:///  will make it connect to Xen, over libvirtd's
UNIX domain socket.

> 
> $ ll info1
> -r-xr-xr-x 1 perform perform 9326 Jul 12 16:50 info1
> $ whoami
> perform
> $ ./info1
> Domains 0: 2 CPUs

This doesn't print schedular info because it is not supported
by the Xen proxy.

> $ su
> Password: 
> # ./info1
> Domains 0: 2 CPUs
> Scheduler = credit
> # chown 0:0 info1;chmod 6555 info1
> # ll info1
> -r-sr-sr-x 1 root root 9326 Jul 12 16:50 info1
> # exit
> $ whoami
> perform
> $ ./info1
> Domains 0: 2 CPUs
> libvir: Xen Daemon error : this function is not supported by the hypervisor: unsupported in xendConfigVersion < 4

Not entirely sure why you get this error message here, but
I strongly recommend against running this setuid regardless.

> $ virsh version
> error: failed to connect to the hypervisor

You need to pass the --readonly flag to virsh

  $ whoami 
  berrange
  $ virsh --readonly version
  Compiled against library: libvir 0.6.3
  Using library: libvir 0.6.3
  Using API: Xen 3.0.1
  Running hypervisor: Xen 3.1.0

And to make it use the libvirtd instead of the proxy give it a URI:

  $ virsh -c xen+unix:/// --readonly schedinfo Domain-0
  Scheduler      : credit
  weight         : 256
  cap            : 0


> $ su root -c "virsh version"
> Password: 
> Compiled against library: libvir 0.6.3
> Using library: libvir 0.6.3
> Using API: Xen 3.0.1
> Running hypervisor: Xen 3.1.0

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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]