Matt Helsley <matthltc@xxxxxxxxxx> writes: > On Wed, Jan 06, 2010 at 02:17:25PM -0600, Serge E. Hallyn wrote: >> Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > <snip> > >> > >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? > > That makes sense but I'm getting a worried about the way those extra > namespace references are popping up in other namespace structs. Seems > like it would be easy to write code that could create reference > cycles and thus leak memory. Perhaps it will require splitting the > references sort of like struct mm_struct? Not yet. If we only grab references as namespace creation time reference cycles are impossible, at least reference cycles outside of the initial namespaces. > The other example of that idea was keeping a syslog_ns reference in > the netns for the iptables printks in ipt_LOG.c. What happens when > one of the CONFIG_*NS options isn't selected? Suddenly we're littering > the struct definitions with #ifdefs and making the code alot more > complicated to test (I suspect). Perhaps it's time to merge all > the CONFIG_*NS options into CONFIG_NAMESPACES? Truthfully I am dubious about the syslog namespace. Certainly the implementations I have seen so far seem half thought out. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
