Messages in this thread | | | Date | Tue, 20 May 2014 14:18:30 +0000 | From | Serge Hallyn <> | Subject | Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces |
| |
Quoting Michael H. Warfield (mhw@WittsEnd.com): > On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote: > > Seth Forshee <seth.forshee@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 | mhw@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-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel
| |