Bug 490191
Summary: | RFE: QEMU consoles: API for access to guest text console data streams | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Jan ONDREJ <ondrejj> |
Component: | libvirt | Assignee: | Daniel Veillard <veillard> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | berrange, clalance, crobinso, markmc, md, pcfe, rjones, veillard, virt-maint, xen-maint |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-29 02:34:30 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 494832, 636033 |
Description
Jan ONDREJ
2009-03-13 18:28:00 UTC
Last comment on upstream bugzilla was:
> Another solution can be to change permissions on pty to 660, leave group to
> tty or change it to a value defined in libvirtd.conf.
>
This doesn't sound unreasonable, you'd probably want to bring it up on
libvir-list or file a bug though.
...
So - can we change the perms on the pty?
I almost filed a new bug on this and remembered we already had it in bugzilla. To reproduce, just run virt-manager as non-root, connect to qemu:///system, look at any VM and go to View->Serial Consoles. Note 'Serial 0' is insensitive because the device node is unreadable by the user. Sounds like we could have libvirt change the permissions on the device node. Any takers to implement that? No, we shouldn't be changing permissions here. It is intentional that these devices are owned by root for qemu:///system instances. The real fix is to get to the position where virt-manager uses qemu:///session for 'local desktop' scenarios, and thus everything runs unprivileged, and the devices would have neccessary ownership already. Okay, moving to F12 target, then. Changing to qemu:///session isn't something we'll be doing for F11. Workaround for people hit by this bug: run "virsh console" from the command line as root or run virt-manager itself as root. Better workaround for systems with only one user: Edit /dev/pts mountpoint in /etc/fstab: none /dev/pts devpts uid=500,gid=5,mode=620 Add this "uid=500" to your UID (id -u). Then remount: mount /dev/pts -o remount and use it. :) Also you can set gid=0,mode=660 or something similar. That is a huge potential security hole even for a single-user system. You really don't want to be exposing the whole of /dev/pts to a non-root user All my /dev/pts/* files are owner by me, only virt* consoles are owned by root. If this user has access to root or using su/sudo, it will has at least same safety as with root user. It's better like running virt-manager as root. May be you can consider fix changing permissions in libvirt, before you final solution will be done. We are not likely to get this bug resolved before F12, though you'll notice that /dev/pts/* for QEMU guests are now owned by user/group pair 'qemu:qemu' instead of root:root, as a result of all QEMU guests now running unprivileged. The long term goal is to provide an API in libvirt for accessing text console data streams, and also to allow QEMU to provide access over VNC. We'll try to address this in F13 instead. (In reply to comment #9) > We are not likely to get this bug resolved before F12, though you'll notice > that /dev/pts/* for QEMU guests are now owned by user/group pair 'qemu:qemu' > instead of root:root, as a result of all QEMU guests now running unprivileged. Does this apply to F11+virt_preview? I still has root:tty ownership for /dev/pts files. But ownership is not a problem for me, but permissions are. There is no other user on my machine, only me. I can add myself to any group, but I still has no access to pts file of qemu, because it's: crw--w---- Can you change it ot crw-rw--- ? (In reply to comment #10) > (In reply to comment #9) > > We are not likely to get this bug resolved before F12, though you'll notice > > that /dev/pts/* for QEMU guests are now owned by user/group pair 'qemu:qemu' > > instead of root:root, as a result of all QEMU guests now running unprivileged. > > Does this apply to F11+virt_preview? Nope, with F11+virt_preview the qemu processes run as root Moving to F13VirtTarget This came up on IRC today. Perhaps I'm missing something. Why can't libvirt XML be changed such that: <serial type='pty'/> becomes <serial type='pty' user='rjones'/> and then have libvirtd do the appropriate chown (or chmod) to the new pty after KVM has created and returned it? That only solves one single use case, that of a single local desktop user accessing the console of a guest running under qemu:///system instance. The goal is that desktop virt should not use qemu:///system at all in the near future, instead using qemu:///session, at which point all VMs would be running as the user's own UID in the first place. For better serial console access in general, we want to add a API to libvirt, so that apps don't need to access the files directly at all, whether local or remote, whether privileged or unprivileged. In parallel, we're also aiming to provide a way to tunnel the character devices over the VNC console connection. I don't really want to add chown'ing as a short term hack for this one use case that we're aiming to deprecated, but rather concentrate on the long term viable solutions. This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Initial patches are posted upstream https://www.redhat.com/archives/libvir-list/2010-August/msg00379.html Moving to rawhide, because this won't be actually included for Fedora until F15. Fixed since release 0.8.6, see virDomainOpenConsole Daniel |