9:21 a.m.
Hi,
Following code snippet, running as non-root user, will throw up a
'Permission denied' RuntimeError.
Could someone kindly guide me the correct way to handle LVM disk as
non-root user? Cause as http://libguestfs.org homepage claims, "libguestfs
doesn't need root permissions." A little confused somehow.
import guestfs
g = guestfs.GuestFS()
g.add_drive_opts("/dev/vg0/disk1", format="raw")
Thanks!
--
Qiu Yu
11:48 a.m.
On Thu, May 30, 2013 at 10:21:42PM +0800, Qiu Yu wrote:
Hi,
Following code snippet, running as non-root user, will throw up a
'Permission denied' RuntimeError.
Could someone kindly guide me the correct way to handle LVM disk as
non-root user?
import guestfs
g = guestfs.GuestFS()
g.add_drive_opts("/dev/vg0/disk1", format="raw")
Libguestfs doesn't do anything different from any other program. I'm
assuming that /dev/vg0/disk1 isn't accessible by non-root (by anyone)
on your host.
On most Linux distros you can add yourself to the 'disk' group
in order to get access to disk devices:
# usermod -G disk -a yourusername
You may need to log out and log in again after doing that.
Cause as http://libguestfs.org homepage claims, "libguestfs
doesn't need root permissions."
Right. This doesn't mean that libguestfs bypasses OS permissions. It
just means that root isn't required unnecessarily.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
9:58 p.m.
On Fri, May 31, 2013 at 12:48 AM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
On Thu, May 30, 2013 at 10:21:42PM +0800, Qiu Yu wrote:
> Hi,
>
> Following code snippet, running as non-root user, will throw up a
> 'Permission denied' RuntimeError.
>
> Could someone kindly guide me the correct way to handle LVM disk as
> non-root user?
>
> import guestfs
> g = guestfs.GuestFS()
> g.add_drive_opts("/dev/vg0/disk1", format="raw")
Libguestfs doesn't do anything different from any other program. I'm
assuming that /dev/vg0/disk1 isn't accessible by non-root (by anyone)
on your host.
On most Linux distros you can add yourself to the 'disk' group
in order to get access to disk devices:
# usermod -G disk -a yourusername
You may need to log out and log in again after doing that.
Unfortunately, the standard 'disk' group permission only applies to
/dev/sdX device nodes, not to device mapper nodes created by LVM commands.
Thank you for the clarification on libguestfs. I'll try to find out other
way to handle LVM device nodes as non-root user.
--
Qiu Yu
2:55 a.m.
On Fri, May 31, 2013 at 10:58:30AM +0800, Qiu Yu wrote:
Unfortunately, the standard 'disk' group permission only
applies to
/dev/sdX device nodes, not to device mapper nodes created by LVM commands.
Actually, it depends on udev rules. On my machine device mapper
nodes very much are owned by the disk group:
$ ll /dev/dm-*
brw-rw----. 1 root disk 253, 0 May 15 13:26 /dev/dm-0
brw-rw----. 1 root disk 253, 1 May 15 13:26 /dev/dm-1
brw-rw----. 1 root disk 253, 10 May 24 13:54 /dev/dm-10
brw-rw----. 1 root disk 253, 11 May 15 13:26 /dev/dm-11
brw-rw----. 1 root root 253, 12 May 29 21:29 /dev/dm-12
[etc]
You can add udev rules to change the ownership. See:
https://wiki.archlinux.org/index.php/Udev
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
3:03 a.m.
On Fri, May 31, 2013 at 3:55 PM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
On Fri, May 31, 2013 at 10:58:30AM +0800, Qiu Yu wrote:
> Unfortunately, the standard 'disk' group permission only applies to
> /dev/sdX device nodes, not to device mapper nodes created by LVM
commands.
Actually, it depends on udev rules. On my machine device mapper
nodes very much are owned by the disk group:
$ ll /dev/dm-*
brw-rw----. 1 root disk 253, 0 May 15 13:26 /dev/dm-0
brw-rw----. 1 root disk 253, 1 May 15 13:26 /dev/dm-1
brw-rw----. 1 root disk 253, 10 May 24 13:54 /dev/dm-10
brw-rw----. 1 root disk 253, 11 May 15 13:26 /dev/dm-11
brw-rw----. 1 root root 253, 12 May 29 21:29 /dev/dm-12
[etc]
You can add udev rules to change the ownership. See:
https://wiki.archlinux.org/index.php/Udev
Rich.
Thanks Richard, you're right. I just find out myself few moments ago.
Actually I'm looking into an issue with OpenStack / Libvirt manipulating
LVM as an image backend. When the logical volume is created, udev rules
will set the ownership to root:disk. After libvirt actually starting an
instance, device node ownership will change to qemu:qemu by libvirt. Then,
if you stop an instance, the device node ownership will change back to
root:root. Seems there's some inconsistency here.
Anyway, it has nothing to do with the libguestfs. Thank you so much for
your help and the information! :)
--
Qiu Yu
3:17 a.m.
On Fri, May 31, 2013 at 04:03:32PM +0800, Qiu Yu wrote:
Actually I'm looking into an issue with OpenStack / Libvirt
manipulating
LVM as an image backend. When the logical volume is created, udev rules
will set the ownership to root:disk. After libvirt actually starting an
instance, device node ownership will change to qemu:qemu by libvirt. Then,
if you stop an instance, the device node ownership will change back to
root:root. Seems there's some inconsistency here.
This is actually a well-known bug in libvirt.
https://bugzilla.redhat.com/show_bug.cgi?id=796072
(marked as a duplicate of a private bug 547546 for some reason --
I will try to get this made non-private)
You can turn off libvirt's ownership management (set dynamic_ownership
= 0 in /etc/libvirt/qemu.conf) however this will cause other problems.
I don't think there is a proper solution to this yet.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
5:39 a.m.
On Fri, May 31, 2013 at 4:17 PM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
On Fri, May 31, 2013 at 04:03:32PM +0800, Qiu Yu wrote:
> Actually I'm looking into an issue with OpenStack / Libvirt manipulating
> LVM as an image backend. When the logical volume is created, udev rules
> will set the ownership to root:disk. After libvirt actually starting an
> instance, device node ownership will change to qemu:qemu by libvirt.
Then,
> if you stop an instance, the device node ownership will change back to
> root:root. Seems there's some inconsistency here.
This is actually a well-known bug in libvirt.
https://bugzilla.redhat.com/show_bug.cgi?id=796072
(marked as a duplicate of a private bug 547546 for some reason --
I will try to get this made non-private)
You can turn off libvirt's ownership management (set dynamic_ownership
= 0 in /etc/libvirt/qemu.conf) however this will cause other problems.
I don't think there is a proper solution to this yet.
Rich.
Richard,
Really thanks for the advice. But seems I'm hitting another permission
issue regarding libguestfs and LVM image.
Following code snippet is stripped from OpenStack data injection logic.
Running as non-root user (stack) will report "guestfs_launch failed" error,
and the debug message shows it failed to open the LVM device node.
I've already set up the group permission ('disk' and 'fuse') for the
'stack' user. Could you shed some lights of what else should I look into?
Thanks!
$ cat test.py
import guestfs
g = guestfs.GuestFS()
g.add_drive_opts("/dev/xenvg/123", format="qcow2")
g.launch()
$ id
uid=501(stack) gid=504(stack) groups=504(stack),6(disk),498(fuse)
$ ll /dev/mapper/xenvg-123
lrwxrwxrwx 1 root root 7 May 31 17:16 /dev/mapper/xenvg-123 -> ../dm-2
$ ll /dev/dm-2
brw-rw---- 1 root disk 253, 2 May 31 18:06 /dev/dm-2
$ python test.py
libguestfs: trace: add_drive_opts "/dev/xenvg/123" "format:qcow2"
libguestfs: trace: add_drive_opts = 0
libguestfs: trace: launch
libguestfs: trace: launch = -1 (error)
Traceback (most recent call last):
File "test.py", line 4, in <module>
g.launch()
File "/usr/lib/python2.6/site-packages/guestfs.py", line 244, in launch
return libguestfsmod.launch (self._o)
RuntimeError: guestfs_launch failed, see earlier error messages
libguestfs: trace: close
$ export LIBGUESTFS_DEBUG=1
$ python test.py
libguestfs: new guestfs handle 0x26a8250
libguestfs: trace: add_drive_opts "/dev/xenvg/123" "format:qcow2"
libguestfs: trace: add_drive_opts = 0
libguestfs: trace: launch
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum
'/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64,
kernel = (null), initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
checking modpath /lib/modules/2.6.32-358.6.2.ns8.el6.x86_64 is a directory
picked vmlinuz-2.6.32-358.6.2.ns8.el6.x86_64 because modpath
/lib/modules/2.6.32-358.6.2.ns8.el6.x86_64 exists
supermin helper [00000ms] finished creating kernel
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/base.img
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles
supermin helper [00015ms] visiting /usr/lib64/guestfs/supermin.d/init.img
supermin helper [00015ms] adding kernel modules
supermin helper [00080ms] finished creating appliance
libguestfs: [00083ms] begin testing qemu features
libguestfs: [00097ms] finished testing qemu features
libguestfs: accept_from_daemon: 0x26a8250 g->state = 1
[00098ms] /usr/libexec/qemu-kvm \
-global virtio-blk-pci.scsi=off \
-drive file=/dev/xenvg/123,cache=off,format=qcow2,if=virtio \
-nodefconfig \
-enable-kvm \
-nodefaults \
-nographic \
-m 500 \
-no-reboot \
-device virtio-serial \
-serial stdio \
-chardev socket,path=/tmp/libguestfssaaw6T/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-kernel /var/tmp/.guestfs-501/kernel.30285 \
-initrd /var/tmp/.guestfs-501/initrd.30285 \
-append 'panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off
printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1
TERM=screen-bce ' \
-drive
file=/var/tmp/.guestfs-501/root.30285,snapshot=on,if=virtio,cache=unsafeqemu-kvm:
-drive file=/dev/xenvg/123,cache=off,format=qcow2,if=virtio: could not open
disk image /dev/xenvg/123: Invalid argument
libguestfs: child_cleanup: 0x26a8250: child process died
libguestfs: trace: launch = -1 (error)
Traceback (most recent call last):
File "test.py", line 4, in <module>
g.launch()
File "/usr/lib/python2.6/site-packages/guestfs.py", line 244, in launch
return libguestfsmod.launch (self._o)
RuntimeError: guestfs_launch failed, see earlier error messages
libguestfs: trace: close
libguestfs: closing guestfs handle 0x26a8250 (state 0)
--
Qiu Yu
6:25 a.m.
On Fri, May 31, 2013 at 06:39:53PM +0800, Qiu Yu wrote:
[00098ms] /usr/libexec/qemu-kvm \
-global virtio-blk-pci.scsi=off \
-drive file=/dev/xenvg/123,cache=off,format=qcow2,if=virtio \
-nodefconfig \
-enable-kvm \
-nodefaults \
-nographic \
-m 500 \
-no-reboot \
-device virtio-serial \
-serial stdio \
-chardev socket,path=/tmp/libguestfssaaw6T/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-kernel /var/tmp/.guestfs-501/kernel.30285 \
-initrd /var/tmp/.guestfs-501/initrd.30285 \
-append 'panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off
printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1
TERM=screen-bce ' \
-drive
file=/var/tmp/.guestfs-501/root.30285,snapshot=on,if=virtio,cache=unsafeqemu-kvm:
-drive file=/dev/xenvg/123,cache=off,format=qcow2,if=virtio: could not open
disk image /dev/xenvg/123: Invalid argument
I'm assuming it's because the format is wrong (ie. not qcow2 but raw).
The error message is a little bit obscure and could be better, but we
do rely on qemu printing something sensible instead of just "Invalid
argument".
What happens if you do:
file -bsL /dev/xenvg/123
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
12:28 a.m.
On Fri, May 31, 2013 at 7:25 PM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
On Fri, May 31, 2013 at 06:39:53PM +0800, Qiu Yu wrote:
> [00098ms] /usr/libexec/qemu-kvm \
> -global virtio-blk-pci.scsi=off \
> -drive file=/dev/xenvg/123,cache=off,format=qcow2,if=virtio \
> -nodefconfig \
> -enable-kvm \
> -nodefaults \
> -nographic \
> -m 500 \
> -no-reboot \
> -device virtio-serial \
> -serial stdio \
> -chardev socket,path=/tmp/libguestfssaaw6T/guestfsd.sock,id=channel0
\
> -device
virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
> -kernel /var/tmp/.guestfs-501/kernel.30285 \
> -initrd /var/tmp/.guestfs-501/initrd.30285 \
> -append 'panic=1 console=ttyS0 udevtimeout=300 no_timer_check
acpi=off
> printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1
> TERM=screen-bce ' \
> -drive
>
file=/var/tmp/.guestfs-501/root.30285,snapshot=on,if=virtio,cache=unsafeqemu-kvm:
> -drive file=/dev/xenvg/123,cache=off,format=qcow2,if=virtio: could not
open
> disk image /dev/xenvg/123: Invalid argument
I'm assuming it's because the format is wrong (ie. not qcow2 but raw).
The error message is a little bit obscure and could be better, but we
do rely on qemu printing something sensible instead of just "Invalid
argument".
Oh, yes. It's indeed the wrong 'format' argument causing the issue. Sorry
I'm not familiar with libguestfs, 'invalid argument' should be an obvious
hint for me to follow on.
For others who might interests, if you use qcow2 image with OpenStack and
choose LVM as image backend, nova libvirt driver will convert it raw when
creating a new instance. However, data injection using libguestfs will
still assuming the it is qcow2 format, hence hit the above issue. Not sure
it is a bug or not, probably one should specify "use_cow_images = False" to
avoid the problem in this case.
--
Qiu Yu
3:57 a.m.
On Sat, Jun 01, 2013 at 01:28:20PM +0800, Qiu Yu wrote:
For others who might interests, if you use qcow2 image with OpenStack
and
choose LVM as image backend, nova libvirt driver will convert it raw when
creating a new instance. However, data injection using libguestfs will
still assuming the it is qcow2 format, hence hit the above issue. Not sure
it is a bug or not, probably one should specify "use_cow_images = False" to
avoid the problem in this case.
Yes, this sounds like a Nova bug.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4:05 a.m.
On 06/01/2013 02:27 PM, Richard W.M. Jones wrote:
On Sat, Jun 01, 2013 at 01:28:20PM +0800, Qiu Yu wrote:
> For others who might interests, if you use qcow2 image with OpenStack and
> choose LVM as image backend, nova libvirt driver will convert it raw when
> creating a new instance.
IIUC, that's the reason, why it converts to raw --
https://github.com/openstack/nova/commit/ff9d353b
-------------------------
"This uses 'qemu-img' to convert images that are not 'raw' to be
'raw'.
By doing so, it
a.) refuses to run uploaded images that have a backing image reference
(LP: #853330, CVE-2011-3147)
b.) ensures that when FLAGS.use_cow_images is False, and the libvirt
xml written specifies 'driver_type="raw"' that the disk referenced
is also raw format. (LP: #837102)
c.) removes compression that might be present to avoid cpu bottlenecks
(LP: #837100)
It does have the negative side affect of using more space in the case where
the user uploaded a qcow2 (or other advanced image format) that could have
been used directly by the hypervisor. That could, later, be remedied by
another 'qemu-img convert' being done to the "preferred" format of the
hypervisor."
-------------------------
It also does it during nova-image-create. A small write-up on how/why --
http://kashyapc.wordpress.com/2013/03/11/openstack-nova-image-create-unde...
However, data injection using libguestfs will
> still assuming the it is qcow2 format, hence hit the above issue.
Not sure
> it is a bug or not, probably one should specify "use_cow_images = False"
to
> avoid the problem in this case.
Yes, this sounds like a Nova bug.
Rich.
--
/kashyap
6:29 a.m.
On Fri, May 31, 2013 at 06:39:53PM +0800, Qiu Yu wrote:
$ cat test.py
import guestfs
g = guestfs.GuestFS()
g.add_drive_opts("/dev/xenvg/123", format="qcow2")
Another option is to completely omit the 'format = ...' option.
Then libguestfs will autodetect the format for you.
However this is not as secure as specifying the format:
http://libguestfs.org/guestfs.3.html#cve-2010-3851
so in production code you should specify the format if you know it,
especially if the guest is not trusted.
In recent libguestfs >= 1.20 you can also query the format using:
`g.disk_format (filename)' but you should still be careful that
you don't accidentally hit CVE-2010-3851.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
4192
days inactive
4194
days old
11 comments
3 participants
participants (3)
-
Kashyap Chamarthy -
Qiu Yu -
Richard W.M. Jones