Description of problem: without root: $ virt-sandbox -c lxc:/// -- /bin/date libvirt-sandbox-init-common: cannot open /dev/tty2: Permission denied (virt-sandbox:14606): Libvirt.GLib-CRITICAL **: cannot finish stream: stream had unexpected termination with root: $ sudo virt-sandbox -c lxc:/// -- /bin/date Thu Jan 24 22:10:09 EST 2013 Version-Release number of selected component (if applicable): Fedora 18 $ virt-sandbox --version libvirt-sandbox version 0.1.0 Additional information: Using the `-l` switch changes the error message to /dev/tty3, but is otherwise no different. I couldn't try the QEMU version for other reasons, so this possibly only happens when using LXC.
I am seeing this as well, and can confirm that it only happens with LXC.
I am not sure about how much support we can give for running these commands as non root, since they could have security implications. Running privledged apps within a lxc container has to be looked at closely.
> Running privledged apps within a lxc container has to be looked at closely. This is unfortunate (it really limits the usefulness of a sandbox if only root can launch one), but makes sense. I don't suppose running non-root apps within LXC (which was my intention here) would be any more likely to be supported, since LCX itself would otherwise need to be setuid root to set up a container? The wording in the manpage of the --privileged flag is a little unclear: > Retain root privileges inside the sandbox, rather than dropping privileges to match the current user identity "retain" sounds like you need to run it as root, but "the current user" sounds like you don't necessarily need to be root.
You could always use policycoreutils-sandbox man sandbox That works as non -root. Only implements file system container though.
If this cannot be fixed, then please add this information to the man page and add a proper error message to virt-sandbox that tells users that root privileges are required.
It is certainly intended that this work, but there are still issues we're trying to deal with here. NB, you can also use 'virt-sandbox -c qemu:///session /some/command', which does work as non-root. Only accessing lxc:/// or qemu:///system as non-root fails. Normally when you start a sandbox, the user you get inside the sandbox will match the uid of your current user. The '--privileged' is a way to ensure you always get root inside the sandbox. eg if you ran this as user 'berrange' virt-sandbox -c qemu:///session /some/command it would run /some/command as user 'berrange' inside the sandbox. Using --privileged, causes it to run as 'root' inside the sandbox. I'll see about clarifying this further in the man page
(In reply to Daniel Berrange from comment #6) > It is certainly intended that this work, but there are still issues we're > trying to deal with here. > > NB, you can also use 'virt-sandbox -c qemu:///session /some/command', > which does work as non-root. Only accessing lxc:/// or qemu:///system as > non-root fails. This fails due to selinux: $ virt-sandbox -c qemu:///session /usr/bin/id Unable to start sandbox: Failed to create domain: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/boot/vmlinuz-3.10.3-300.fc19.x86_64': Operation not permitted The type of the kernel image is boot_t, which is not changed with running restorecon as root.
Bug 987225 is a dupe of this, but on f19 so I wasn't sure if I should mark it as such. Also, running: virt-sandbox -c qemu:///session /usr/bin/id as root now fails with: Unable to start sandbox: Failed to create domain: Unable to read from monitor: Connection reset by peer and in the log: Aug 07 11:44:41 gaspode libvirtd[753]: Unable to read from monitor: Connection reset by peer Aug 07 11:44:41 gaspode libvirtd[753]: cannot lookup default selinux label for /tmp/libvirt-sandbox-initrd-wYx10u libvirt* is at 1.0.5.5-1.fc19, libvirt-sandbox* is at 0.2.0-1.fc19. I don't see libvirt-sandbox 0.5 for <f20 on koji, should I wait for that?
Since F18 is end-of-life, this is unlikely to be fixed there, so reassigning to F19.
*** Bug 987225 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still failing under F21, libvirt-sandbox 0.5.1-4.fc21 non-root: > $ virt-sandbox -c qemu:///session /usr/bin/id > libvirt-sandbox-init-qemu: readall: cannot open fscache.ko root: > $ sudo virt-sandbox -c qemu:///session /usr/bin/id > Swipe your finger across the fingerprint reader > Unable to start sandbox: Failed to create domain: internal error: process exited while connecting to monitor: qemu: could not load kernel '/var/run/libvirt-sandbox/sandbox/vmlinuz': Permission denied non-root: (This asked for root permission, via gnome UI, anyway): > $ virt-sandbox -c lxc:/// -- /bin/date > /usr/libexec/libvirt-sandbox-init-common: Unable to load config /etc/libvirt-sandbox/scratch/sandbox.cfg: Permission denied log: > type=AVC msg=audit(1424205595.608:507): avc: denied { read } for pid=6764 comm="libvirt-sandbox" name="sandbox.cfg" dev="dm-2" ino=11013754 scontext=system_u:system_r:svirt_lxc_net_t:s0:c576,c657 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=file permissive=0 > type=SYSCALL msg=audit(1424205595.608:507): arch=x86_64 syscall=open success=no exit=EACCES a0=405ba0 a1=0 a2=0 a3=11f items=0 ppid=6763 pid=6764 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm=libvirt-sandbox exe=/usr/libexec/libvirt-sandbox-init-common works when run as root.
This is still reproducible with QEMU/KVM As non-root: $ virt-sandbox -c qemu:///session -- /bin/date libvirt-sandbox-init-qemu: readall: cannot open fscache.ko As root: $ getenforce Permissive $ virt-sandbox -c qemu:///system -- /bin/date Unable to start sandbox: Failed to create domain: internal error: process exited while connecting to monitor: qemu: could not load kernel '/var/run/libvirt-sandbox/sandbox/vmlinuz': Permission denied Version ------- $ uname -r; rpm -q libvirt-sandbox 4.0.0-0.rc1.git1.1.fc23.x86_64 libvirt-sandbox-0.5.1-4.fc22.x86_64 Daniel Berrange on IRC mentioned the below about the root cause: there's a problem that fedora has renamed the kenrel modules, they now have .ko.xz instead of .ko
libvirt-glib-0.2.1-1.fc22, libvirt-sandbox-0.6.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libvirt-glib-0.2.1-1.fc22,libvirt-sandbox-0.6.0-1.fc22
Package libvirt-glib-0.2.1-1.fc22, libvirt-sandbox-0.6.0-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-glib-0.2.1-1.fc22 libvirt-sandbox-0.6.0-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-11131/libvirt-glib-0.2.1-1.fc22,libvirt-sandbox-0.6.0-1.fc22 then log in and leave karma (feedback).
libvirt-glib-0.2.1-1.fc22, libvirt-sandbox-0.6.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.