Re: Remaining work for userns

[ebiederm@xmission.com (Eric W. Biederman)]

"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Matt Helsley (matthltc@us.ibm.com):
>> On Thu, Jul 29, 2010 at 05:39:57PM -0500, Serge E. Hallyn wrote:
>> > Quoting Matt Helsley (matthltc@us.ibm.com):
>> > > On Thu, Jul 29, 2010 at 02:58:12PM -0500, Serge E. Hallyn wrote:
>> 
>> <snip>
>> 
>> > 
>> > BTW in the past the only reason I saw for keeping ns cgroup was
>> > to lock tasks into a devices cgroup.  Until that lazy guy who was
>> > going to do it gets off his butt and implements user namespaces,
>> > you'll just have to use LSMs, which is the right way.
>> 
>> And the only missing piece of userns is replacing the cred checks
>> right? If so, it might be possible to come up with a coccinelle semantic
>> patch which would do all/most of the hard work -- depends on whether the
>> all the checks fit a small number of semantic patterns.
>
> I think the thing that always puts the brakes on when I get started
> is siginfo_t.  We need some way to reference user namespaces in there,
> without enforcing lifetime rules on siginfo.

As I recall signal delivery in the kernel lands the signal in the
queue of the destination process before the syscall returns.  If that
is true we should be able to handle signal delivery by just doing
whatever conversions are needed during delivery.

aka the userns should just be task->nsproxy->user_ns for
task->signal->queue.  We cannot unshare the user namespace so there
are no nasty races.

I am reminded that I may want to play with the user namespace and
unshare when I get setns refresh and reviewed for inclusion.  Still
none of that should affect the fact that a task should never be
able to change user namespaces.

> What you mention is definately a chunk as well, so if you are interested
> in pursuing that that'd be great.
>
> Also, reviewing the patches at the top of
> http://git.kernel.org/?p=linux/kernel/git/sergeh/linux-cr.git;a=shortlog;h=refs/heads/userns.feb16.1
> to give us some fresh feedback on the general approach is
> valuable.
>
> And from there, the whole discussion (which we've had several times
> in the past) about how to have the VFS map userids should probably be
> had again.  (I believe august 2008 was the last time we really got
> into that)

We now have user_ns_map_uid and user_ns_map_gid in next-next.git
Serge I'm not certain how that interacts with your other work, but
it is definitely something we want to build on.

Eric