Pavel Emelyanov <xemul@openvz.org> writes:
quoted text
>>> I agree, that we should probably destroy this one when the task calls 
>>> unshare, but trying to keep this list relevant is useless.
>>>   
>> A very tricky question: Let's assume we have a process with two threads.
>> The undo structure is shared, as per opengroup standard.
>> Now one thread calls unshare(CLONE_NEWIPC). What should happen? We 
>> cannot destroy the undo structure, the other thread might be still 
>> interested in it.
>> If we allow sys_unshare() for multithreaded processes with CLONE_NEWIPC 
>> and without CLONE_SYSVSEM, then we must handle this case.
>
> Hm... I'd simply disable creating any new namespaces for threads.
> I think other namespaces developers agree with me. Serge, Suka, Eric
> what do you think?

I almost agree.  sys_unshare() in a multithreaded process breaks
all kinds of user space libs.  So you can only reasonably look at
the problem as what we do with linux tasks that share some things
and not others.  The posix/opengroup notion of processes and threads
are a distraction.

In this case requiring it appears that to require unsharing both
CLONE_SYSVSEM and CLONE_NEWIPC at the same time.  (i.e. unshare
of CLONE_SYSVSEM should fail if CLONE_NEWIPC is not also specified).

Then to make it work we make unshare of SYSVSEM succeed when it is
not shared.

This looks like about a 5 line patch or two.

The effect is because we don't support unsharing of SYSVSEM currently
we don't support a threaded process unsharing the ipc namespace.

Eric
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/