Re: [RFC, PATCH] fix SEM_UNDO with namespaces

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
> Pavel Emelyanov <xemul@xxxxxxxxxx> writes:
> >>> 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

Eric, does the following patch correctly interpret your recommendation?

Pavel does it make sense to you?

thanks,
-serge