Re: Supporting CLONE_NEWPID namespaces and process-shared mutexes supported?

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 25/10/2017 10:33, Torvald Riegel wrote:
> On Tue, 2017-10-24 at 14:45 -0700, Carlos O'Donell wrote:
>> We use tid's in the internals of a mutex to identify owner. This is
>> considered unique for the system (though it has an ABA pid-reuse
>> problem).
> The owner is only required for some mutex types.  Are these types
> required for the intended use cases?
>

My understanding from previous discussion is to document the pitfalls
and limitation of using POSIX process-shared synchronization along 
with Linux only APIs that do not guarantee pid uniqueness.

Currently we have the following supported process-shared
synchronization:

  1. pthread_mutex_t with PTHREAD_PROCESS_SHARED
  2. pthread_rwlock_t with PTHREAD_PROCESS_SHARED
  3. pthread_cond_t with PTHREAD_PROCESS_SHARED
  4. pthread_barrier_t with PTHREAD_PROCESS_SHARED
  5. posix semaphore with positive pshared
  6. posix shared memory 
  7. SysV semaphore
  8. SysV shared memory

I think SysV API should work with CLONE_NEWPID unless user explicit
call clone with CLONE_NEWIPC.  Glibc posix shared memory will also 
work if the process shares the same filesystem with visibility to the
shmfs (and user can disable it by issuing clone with CLONE_NEWNS).

The other primitives are all based internally on futex on Linux
and afaik there is no namespace isolation for futex operations.
POSIX semaphore and pthread_barrier should not have issues
since they rely only futex values (no external system information
such as the process identifier).

With leads to shared pthread_mutex_t, pthread_rwlock_t, and
pthread_cond_t that does not actually work with CLONE_NEWPID.

What I think it might be controversial is exactly to provide
a process in a namespace external system information (in this
case a global identifier).  I am not sure about possible
security implication on this, but I do see that it is kinda
orthogonal of what CLONE_NEWPID is aiming as information
constriction.

Which lead to a question: what kind of process synchronization
we can not accomplish with current API that in theory should
work with CLONE_NEWPID?