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.