Launchpad has imported 17 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=490191.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-03-13T18:28:00+00:00 Jan wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/0 ------------------------------------------------------------------------ On 2009-03-25T17:27:20+00:00 Mark wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/1 ------------------------------------------------------------------------ On 2009-05-05T12:17:38+00:00 Mark wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/2 ------------------------------------------------------------------------ On 2009-05-05T12:25:47+00:00 Daniel wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/3 ------------------------------------------------------------------------ On 2009-05-05T13:18:36+00:00 Mark wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/4 ------------------------------------------------------------------------ On 2009-05-05T13:29:39+00:00 Jan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/5 ------------------------------------------------------------------------ On 2009-05-05T14:06:34+00:00 Daniel wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/6 ------------------------------------------------------------------------ On 2009-05-05T14:21:45+00:00 Jan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/7 ------------------------------------------------------------------------ On 2009-05-21T15:20:16+00:00 Mark wrote: See also: https://fedoraproject.org/wiki/Features/VirtPrivileges Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/8 ------------------------------------------------------------------------ On 2009-09-15T10:42:39+00:00 Daniel wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/9 ------------------------------------------------------------------------ On 2009-09-17T11:59:45+00:00 Jan wrote: (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--- ? Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/10 ------------------------------------------------------------------------ On 2009-09-21T13:26:10+00:00 Mark wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/11 ------------------------------------------------------------------------ On 2009-10-20T15:50:00+00:00 Richard wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/12 ------------------------------------------------------------------------ On 2009-10-20T16:04:53+00:00 Daniel wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/13 ------------------------------------------------------------------------ On 2009-11-16T09:51:59+00:00 Bug wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/14 ------------------------------------------------------------------------ On 2010-08-23T16:51:31+00:00 Daniel wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/30 ------------------------------------------------------------------------ On 2011-06-29T02:34:30+00:00 Daniel wrote: Fixed since release 0.8.6, see virDomainOpenConsole Daniel Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/comments/31 ** Changed in: libvirt (Fedora) Status: Unknown => Won't Fix ** Changed in: libvirt (Fedora) Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/523148 Title: virsh console does not work (/dev/pts/1: Permission denied) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/523148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
