Re: [libvirt] inability to open local read-only connection

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: $ ll info1 -r-xr-xr-x 1 perform perform 9326 Jul 12 16:50 info1 $ whoami perform $ ./info1 Domains 0: 2 CPUs $ 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 $ virsh version error: failed to connect to the hypervisor $ 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 As you can see, even virsh needs to be run as root in order to connect to the hypervisor. To help, I have attached both the source code and the executable I was using. Please let me know if anything else is required to get this problem resolved. Thanks. John -----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Monday, March 01, 2010 7:58 AM To: Tavares, John Cc: libvir-list(a)redhat.com Subject: Re: [libvirt] inability to open local read-only connection On Thu, Feb 25, 2010 at 02:34:02PM -0600, Tavares, John wrote: A readonly connection essentially just goes to a separate UNIX socket, which has more relaxed permissions (mode 0777, instead of 0700). The kernel does the permissions checking when attempting to open it, so it should be using the effective ID. I'd suggest trying to strace your process & see where it fails, and/or run with LIBVIRT_DEBUG=1 environemnt variable set. 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 :|