Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > So i was thinking about how to safely but incrementally introduce > > targeted capabilities - which we decided was a prereq to making VFS > > handle user namespaces - and the following seemed doable. My main > > motivations were (in order): > > > > 1. don't make any unconverted capable() checks unsafe > > 2. minimize performance impact on non-container case > > 3. minimize performance impact on containers > > My motivation is a bit different. I would like to get to the > unprivileged creation of new namespaces. It looks like this gets us > 90% of the way there, with only potential uid confusion issues left. > > I still need to handle getting all caps after creation but otherwise I > think I have a good starter patch that achieves all of your goals. > > Of course kill_permission needs the checks you have suggested as well. > > Eric > > > >From db104af741b5f0a2f128688905498cae68fbbde2 Mon Sep 17 00:00:00 2001 > From: Eric W. Biederman <ebiederm@xxxxxxxxxxxx> > Date: Wed, 6 Jan 2010 08:26:21 -0800 > Subject: [PATCH] security: Make capabilities relative to the user namespace. > > - Introduce ns_capable to test for a capability in a non-default > user namespace. > - Teach cap_capable to handle capabilities in a non-default > user namespace. So yeah, I didn't address the whole has_capability junk. Feh. So do you intend to tag all namespaces with the userns which created it? So sys_hostname() can check utsname->uts_ns->creator, and net ioctl SIOCSIFNAME checks struct net->creator? -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
