Quoting Michael H. Warfield (m...@wittsend.com): > On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote: > > Seth Forshee <seth.fors...@canonical.com> writes: > > > > > What I set out for was feature parity between loop devices in a secure > > > container and loop devices on the host. Since some operations currently > > > check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish > > > this is to push knowledge of the user namespace farther down into the > > > driver stack so the check can instead be for CAP_SYS_ADMIN in the user > > > namespace associated with the device. > > > > > > That said, I suspect our current use cases can get by without these > > > capabilities. Really though I suspect this is just deferring the > > > discussion rather than settling it, and what we'll end up with is little > > > more than a fancy way for userspace to ask the kernel to run mknod on > > > its behalf. > > > A fancy way to ask the kernel to run mknod on its behalf is what > > /dev/pts is. > > > When I suggested this I did not mean you should forgo making changes to > > allow partitions and the like. What I itended is that you should find a > > way to make this safe for users who don't have root capabilities. > > I like to think in terms of the "rootless" configurations where "root" > per se is not absolute and everything is framed in terms of > capabilities. > > > Which possibly means that mount needs to learn how to keep a more > > privileged user from using your new loop devices. > > Not sure I got that one. As user with "more" privileges may or may not > have access dependent on the congruence of the privileges. They're not
Yes so in this case by more privileged' he meant a privileged user in a userns which is ancestor to the current userns. It is in fact *more* privileged than any user in the current userns. > heiarchial. If someone has that "priv" then they have access. If they They are in fact implicitly hierarchical due to the hierarchical userns design. > do not, they do not. > > > To get to the point where this is really and truly usable I expect to be > > technically daunting. > > Most technically non-trivial problems generally are. > > > Ultimately the technical challenge is how do we create a block device > > that is safe for a user who does not have any capabilities to use, and > > what can we do with that block device to make it useful. > > Concur. It boils down to privilege management and access. Absolutely > concur. > > > Only when the question is can this kernel functionality which is > > otherwise safe confuse a preexisting setuid application do namespace > > or container bits significantly come into play. > > Ah... Admittedly it's not as late as our conversation at LinuxPlumbers > last year in NOLA but... Maybe late at night but I failed to parse the > above. > > > Eric > > Regards, > Mike > -- > Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! > > _______________________________________________ > lxc-devel mailing list > lxc-de...@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel -- 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/
