> Can you please comment on that? Dear Marian and others,
from an abstract point of view, i think we can compare the "id-shifting" issue with the provision of an ethernet device to the container: You may let it appear inside as raw device or in an abstract way. If it's not virtualized, there is no real possibility for provision from outside and there may be a clash between different containers on the same hosting plattform and the container is not independent from the concrete host resources anymore. With the introduction of the id shifting feature, we got the virtualisation of the ids for running processes through the mapping, but for the mounted filesystems in the moment this is a "raw" style behaviour. This approach was probably first most driven by the "superuser security problem". For the "common"(?) usecase, this might be just the right mode because the container local filesystem may be treated as private to the container. And this usecase, there is no sharing conflict between other containers or while migrating to another host (because one just may move a complete, "isolated" file system tree). But with your usecase and other "sharing" szenarios, it would be better to provide the filesystem in a virtualized way with respect to the id namespace. Because with this, the concrete id mapping defined for an container at runtime (i.e. startup) is used and then there is a single (and stateless!) responsibility for this mapping. Therefore, there is a good reason to offer both modes (unmapped and mapped id). But no other modes (like another independet mapping) should be provided in the concern of LXC. Of course, such an id mapper filesystem might be a smart tool for general, tricky purposes, like a loop device. But it should be released in a independent project, imho. Guido _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
