[Devel] Re: [PATCH 1/1] RFC: taking a crack at targeted capabilities

[Eric W. Biederman]

Matt Helsley <matthltc at us.ibm.com> writes:

> On Wed, Jan 06, 2010 at 02:17:25PM -0600, Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> > "Serge E. Hallyn" <serue at us.ibm.com> writes:
>
> <snip>
>
>> > >From db104af741b5f0a2f128688905498cae68fbbde2 Mon Sep 17 00:00:00 2001
>> > From: Eric W. Biederman <ebiederm at xmission.com>
>> > 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 at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers