"Eric W. Biederman" <ebied...@xmission.com> writes: > It is a wider issue. Capabilities cover most of places in the kernel > where the kernel tests if you have privilege but there are other > filesystems like devtmpsfs, and the occasional silly piece of kernel > code that should be using capabilities but is not. Beyond the kernel > there are files like /etc/shadow that only root is allowed to read. > > Which all boils down to the fact that for the inconvience of using a > separate range of uids a lot of other problems just go away.
Hi. Thanks for the clarifications here, which make a lot of sense. > Not being able to share the host filesystem into a container is a > downside of the current implementation. In principle you can have an > overlay style filesystem that munges the uids and removes this > limitation, but that doesn't currently exist. Yes, given the design means I can't just have an identity UID/GID mapping, this seems like the building block I'm missing to get namespace IDs instead of host IDs stored on disk. I imagine it might be fairly straightforward for me to take a simple 'example' stacked filesystem like wrapfs and teach it to map UIDs and GIDs. I'll have to take a look. Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
