containers and host user space shared when created using virsh

I’m trying to setup a container in redhat. The container should also run redhat version same as that of host. While exploring about these, I came across virsh and docker. Virsh supports host based containers and shares user space with host machine. Here I got confused with user space. Whether it mean filesystem space or some thing else. Can anyone clarify me on this? Also in which scenarios/cases virsh(host based container) can be used so that I can conclude whether its better to use virsh or docker. In my case i need to set up a redhat container in redhat host and run multiple instances of same process in each container. The containers should exchange data across each other without using network interface.

  • Kubernetes NFS server is taking 100% cpu
  • Kubernetes - Creating a specific namespace for “services”
  • Running 'docker-compose up' raises “No module named fnctl” error on Windows
  • Can't see django site being run in docker container on localhost
  • List files in exited container
  • Meteor packages.json error workaround when upgrading from 1.2 to 1.3 and deploying in a docker container
  • Building in docker and deploying in ubuntu [closed]
  • Way to delete the images from Private Docker Registry
  • Cannot restart the MySQL Docker container, gives errors like `Can't open the mysql.plugin table` and `Table 'mysql.user' doesn't exist`
  • docker pull inside docker in a private Hub didn't work
  • How to setup multiple docker containers for multiple developers on the same host?
  • How to run docker-compose as root user Docker Cloud
  • 2 Solutions collect form web for “containers and host user space shared when created using virsh”

    This should help clarify: http://rhelblog.redhat.com/2015/07/29/architecting-containers-part-1-user-space-vs-kernel-space/

    It sounds like you really want to use Docker with -v bind mounts to share data. That is an article for a future day 🙂

    https://docs.docker.com/userguide/dockervolumes/

    Current Kernels do not support yet the user namespace.
    This is a known limitation of current containerization solutions. Unfortunately, usernamespace was implemented in latest kernel releases (staring from kernel 3.8) http://kernelnewbies.org/Linux_3.8 though it is not yet enabled in many mainstream distributions.

    This is one of the strongest limitations of containers right now, if you are root (ID 1) in a container, you are root across the machine operating the container.

    This is a problem affecting any product based on LXC though there is a strong push to fix this. It is actually a needed thing!

    Alternatives is to go for hard Selinux jailing or work with underprivileged users accounts and assigning different users per container.

    From Libvirt documentation https://libvirt.org/drvlxc.html:

    User and group isolation
    If the guest configuration does not list any ID mapping, then the user and group IDs used inside the container will match those used outside the container. In addition, the capabilities associated with a process in the container will infer the same privileges they would for a process in the host. This has obvious implications for security, since a root user inside the container will be able to access any file owned by root that is visible to the container, and perform more or less any privileged kernel operation. In the absence of additional protection from sVirt, this means that the root user inside a container is effectively as powerful as the root user in the host. There is no security isolation of the root user.

    The ID mapping facility was introduced to allow for stricter control over the privileges of users inside the container. It allows apps to define rules such as “user ID 0 in the container maps to user ID 1000 in the host”. In addition the privileges associated with capabilities are somewhat reduced so that they cannot be used to escape from the container environment. A full description of user namespaces is outside the scope of this document, however LWN has a good write-up on the topic. From the libvirt point of view, the key thing to remember is that defining an ID mapping for users and groups in the container XML configuration causes libvirt to activate the user namespace feature.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.