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

[Chris Bainbridge]

Binary package hint: libvirt-bin

$ virsh console host1
Connecting to uri: qemu:///system
Connected to domain host1
Escape character is ^]
11:17:06.610: error : vshRunConsole:77 : unable to open tty /dev/pts/1: Permission denied

[Jan (jan-redhat-bugs)]

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

[Mark (mark-redhat-bugs)]

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?

[Mark (mark-redhat-bugs)]

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?

[Daniel (daniel-redhat-bugs)]

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.

[Mark (mark-redhat-bugs)]

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.

[Jan (jan-redhat-bugs)]

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.

[Daniel (daniel-redhat-bugs)]

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

[Jan (jan-redhat-bugs)]

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.

[Mark (mark-redhat-bugs)]

See also:

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

[Daniel (daniel-redhat-bugs)]

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.

[Jan (jan-redhat-bugs)]

(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--- ?

[Mark (mark-redhat-bugs)]

(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

[Richard (richard-redhat-bugs)]

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?

[Daniel (daniel-redhat-bugs)]

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.

[Bug (bug-redhat-bugs)]

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

[Chris Bainbridge (chris-bainbridge)]

Confirmed under Karmic.

[Chuck Short (zulcss)]

http://libvirt.org/git/?p=libvirt.git;a=blobdiff;f=src/qemu/qemu_monitor_text.c;h=5b9ced21402fe1712f0e4db89bdf9f1d695159ff;hp=ab361c6f2b528592d1f96bb1846483fdf80536b1;hb=c0a9b6a5338e54b64a4a28415ffbdb6bcc2b38c5;hpb=aee70b7482b4eb7c69f5cacfeb364000294300aa

Is the supposed fix.

[Julien Lavanchy-Delhomme (jules-ld)]

I have approximatively the same problem on Lucid server - alpha 3.

# virsh console guest1
Connected to domain guest1
Escape character is ^]
14:25:40.056: error : vshRunConsole:77 : unable to open tty /dev/pts/3 : No such file or directory

When I dump the configuration of my VM, something is wrong with the path "/dev/pts/3" (there is a carriage return after the path).

# virsh dumpxml guest1
<domain type='kvm' id='2'>
  <name>guest1</name>
...
 <serial type='pty'>
'/> <source path='/dev/pts/3
      <target port='0'/>
    </serial>
'> <console type='pty' tty='/dev/pts/3
'/> <source path='/dev/pts/3
      <target port='0'/>
    </console>
...
</domain>

[Chris Bainbridge (chris-bainbridge)]

Jules: I think your issue is different - my bug is about permissions but the device path is ok. Your bug appears to have some weird device path - causing the device to not be found. Check your XML definition in /etc/libvirt/qemu/guest1.xml

[Julien Lavanchy-Delhomme (jules-ld)]

Yes I think you are true. But the Debian bug (debbugs #567818) in relation to this bug is the same. Maybe I could try to report my bug as a new one?

I already check the xml configuration of my VM. Apparently, this path is created directly by the hypervisor when the VM is started. I tried to set up it in the configuration file with "virsh edit", but libvirt didn't commit the modification (even if the VM is not started).

And apparently, this bug is fixed in libvirt 0.7.5 (http://libvirt.org/git/?p=libvirt.git;a=commit;h=c0a9b6a5338e54b64a4a28415ffbdb6bcc2b38c5).

[Scott Moser (smoser)]

I can verify that the linked git patch fixes the problem that Jules saw above.

[Scott Moser (smoser)]

@Jules. I've opened bug 542324 to attach the problem you saw, and subscribed you to that bug.

[Scott Moser (smoser)]

The debian bug above should be un-linked from this bug.
I'm not all together sure that the reported behavior *is* a bug. Has this ever worked?
What I see in lucid, after fixing bug 542324 is that the non-root user cannot use 'console'. Has non-root ever been able to use virsh console ? If so, what was setting permissions correctly ?

$ ls -l /dev/pts/4
crw--w---- 1 root tty 136, 4 2010-03-19 19:27 /dev/pts/4

Those are the permissions that I get on the libvirt created tty.

I believe that the bug reported here is the same as https://bugzilla.redhat.com/show_bug.cgi?id=490191 .

[Dustin Kirkland  (kirkland)]

This is in 0.7.7, which Jamie is trying to get uploaded to Lucid (assuming that we can fix any regressions).

When/if he uploads that version, it will fix this issue.

If we stick with 0.7.5, we can cherry pick that patch.

[Scott Moser (smoser)]

@Dustin,
Where do you see that this is fixed in 0.7.7 ? I see no evidence of that, the RedHat bug is in 'assigned'. Note, as I mentioned above, the debian linked here is incorrect (the debian bug fixes bug 542324, a separate issue).

[Dustin Kirkland  (kirkland)]

@Scott-

Sorry, I was taking Jamie's word for it.

[Jamie Strandboge (jdstrand)]

I think that two different things are being talked about. Chuck mentioned a commit that fixes the bug. That commit is in 0.7.7 but seems unrelated to what Scott is referring to, which is not yet fixed.

[Scott Moser (smoser)]

OK, I'll try to straighten this out.

- This bug was opened against Karmic, reporting an issue where attaching to the console would give 'Permission denied' (see the subject of the bug).
- Jules D and myself tried to use the console in Lucid and ran into an issue with error "unable to open tty /dev/pts/3 : No such file or directory". bug 542324 was opened to address *that* issue in lucid, which was not present in karmic. bug 542324 was fixed using the git commit that Chuck pointed at in this bug, backported to 0.7.5.
- The debian bug (567818) above should not be attached to this bug. However, there is apparently no way to un-attach a linked bug.
- The "Permission denied" error that is the subject of this bug is not fixed in 0.7.7 that I know of. The RedHat/Fedora generally discusses that this is not a trivial thing to fix, and rather a feature that needs to be added.

[Dustin Kirkland  (kirkland)]

As this is a feature that needs to be added to Libvirt, this won't be fixed for Lucid. Marking wont-fix in Lucid, but leaving the bug open for tracking beyond Lucid. Unassigning myself for now.

[Daniel (daniel-redhat-bugs)]

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.

[Daniel (daniel-redhat-bugs)]

Fixed since release 0.8.6, see virDomainOpenConsole

Daniel

[Serge Hallyn (serge-hallyn)]

Per the fedora bug, I believe this should be fixed in natty and oneiric.