virsh console does not work (/dev/pts/1: Permission denied)

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

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.

See also:

https://fedoraproject.org/wiki/Features/VirtPrivileges

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