Bug 490191 - RFE: QEMU consoles: API for access to guest text console data streams
RFE: QEMU consoles: API for access to guest text console data streams
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
: Triaged
Depends On:
Blocks: 494832 libvirtTodoHV
  Show dependency treegraph
 
Reported: 2009-03-13 14:28 EDT by Jan ONDREJ
Modified: 2011-06-28 22:34 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-28 22:34:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan ONDREJ 2009-03-13 14:28:00 EDT
Description of problem:
Crating an domain using virt-manager of "virsh start" do not allow me open virtual serial console. Please change ownership of /dev/pts/# to user, who started virtual machine or set permissions to 660 and change group to an value defined in libvirtd.conf.

Another solution can be change ownership when virsh console command is started.

Version-Release number of selected component (if applicable):
libvirt-0.6.1-1.fc10.i386
virt-manager-0.7.0-1.fc10.i386

How reproducible:
always

Steps to Reproduce:
1. start an virtual machine with serial console enabled (or at least with serial port) as normal user (not root)
2. virsh --connect qemu:///system console machinename
  
Actual results:
unable to open tty /dev/pts/6: Permission denied0


Additional info:
ls -la /dev/pts/6
crw--w---- 1 root tty 136, 6 Mar 13 19:23 /dev/pts/6

Discussion on fedora-virt:
https://www.redhat.com/archives/fedora-virt/2009-March/msg00039.html
Comment 1 Mark McLoughlin 2009-03-25 13:27:20 EDT
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?
Comment 2 Mark McLoughlin 2009-05-05 08:17:38 EDT
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?
Comment 3 Daniel Berrange 2009-05-05 08:25:47 EDT
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.
Comment 4 Mark McLoughlin 2009-05-05 09:18:36 EDT
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.
Comment 5 Jan ONDREJ 2009-05-05 09:29:39 EDT
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.
Comment 6 Daniel Berrange 2009-05-05 10:06:34 EDT
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
Comment 7 Jan ONDREJ 2009-05-05 10:21:45 EDT
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.
Comment 8 Mark McLoughlin 2009-05-21 11:20:16 EDT
See also:

https://fedoraproject.org/wiki/Features/VirtPrivileges
Comment 9 Daniel Berrange 2009-09-15 06:42:39 EDT
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.
Comment 10 Jan ONDREJ 2009-09-17 07:59:45 EDT
(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--- ?
Comment 11 Mark McLoughlin 2009-09-21 09:26:10 EDT
(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
Comment 12 Richard W.M. Jones 2009-10-20 11:50:00 EDT
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?
Comment 13 Daniel Berrange 2009-10-20 12:04:53 EDT
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.
Comment 14 Bug Zapper 2009-11-16 04:51:59 EST
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
Comment 15 Daniel Berrange 2010-08-23 12:51:31 EDT
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.
Comment 16 Daniel Veillard 2011-06-28 22:34:30 EDT
Fixed since release 0.8.6, see virDomainOpenConsole

Daniel

Note You need to log in before you can comment on or make changes to this bug.