[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250210185824.GB7107@brightrain.aerifal.cx>
Date: Mon, 10 Feb 2025 13:58:24 -0500
From: Rich Felker <dalias@...c.org>
To: Jeffrey Walton <noloader@...il.com>
Cc: musl@...ts.openwall.com, Florian Weimer <fweimer@...hat.com>
Subject: Re: pthread_mutex_t shared between processes with different
pid namespaces
On Mon, Feb 10, 2025 at 01:44:12PM -0500, Jeffrey Walton wrote:
> On Mon, Feb 10, 2025 at 11:13 AM Daniele Personal <d.dario76@...il.com> wrote:
> >
> > On Sat, 2025-02-08 at 09:52 -0500, Rich Felker wrote:
> > > On Sat, Feb 08, 2025 at 03:40:18PM +0100, Daniele Dario wrote:
> > > > Il sab 8 feb 2025, 13:39 Rich Felker <dalias@...c.org> ha scritto:
> > > >
> > > > > On Sat, Feb 08, 2025 at 10:20:45AM +0100, Daniele Dario wrote:
> > > > > > But wouldn't this mean that robust mutexes functionality is
> > > > > > totally
> > > > > > incompatible with pid namespaces?
> > > > >
> > > > > No, only with trying to synchronize *across* different pid
> > > > > namespaces.
> > > > >
> > > > > > If the kernel relies on tid stored in memory by the process
> > > > > > this always
> > > > > > lacks the information about the pid namespace the tid belongs
> > > > > > to.
> > > > >
> > > > > It's necessarily within the same pid namespace as the process
> > > > > itself.
> > > > >
> > > > > Functionally, you should consider different pid namespaces as
> > > > > different systems that happen to be capable of sharing some
> > > > > resources.
> > > >
> > > > Yes, I'm just saying that sharing pthread_mutex_t instances across
> > > > processes within the same pid namespace but on a system with more
> > > > than a
> > > > pid namespace could lead to issues anyway if the stored tid value
> > > > is used
> > > > by the kernel as who to contact without the knowledge of on which
> > > > pid
> > > > namespace.
> > > >
> > > > I not saying this is true, I'm trying to understand and if
> > > > possible,
> > > > improve things.
> > >
> > > That's not a problem. The stored tid is used only in the context of a
> > > process exiting, where the kernel code knows the relevant pid
> > > namespace (the one the exiting process is in) and uses the tid
> > > relative to that. If it didn't work this way, it would be a fatal bug
> > > in the pid namespace implementation, which is supposed to allow
> > > essentially transparent containerization (which includes processes in
> > > the ns being able to use their tids as they could if they were
> > > outside
> > > of any container/in global ns).
> >
> > So, IIUC, the problem of sharing robust pthread_mutex_t instances
> > across different pid namespaces is on the user space side which is not
> > able to distinguish clashes on TIDs. In particular, problems could
> > arise when:
> > * an application tries to unlock a mutex owned by another one with its
> > same TID but on a different pid namespace (but this is an
> > application design problem and libc can't help because TIDs are not
> > unique across different pid namespaces)
> > * an application tries to lock a mutex owned by another one with its
> > same TID but on a different pid namespace: this is a real issue
> > because it could happen
> >
> > I know that pid namespace isolation usually comes also with ipc
> > namespace isolation but it is not a violation to have one without the
> > other. Wouldn't it be a good idea to figure out a way to have a safe
> > way to use robust mutexes shared across different pid namespaces?
>
> It's been a while since I took my computer science classes, but...
>
> It sounds like (to me) the wrong tool is being used for the job. If
> you want a synchronization object that works across processes, then
> you use a semaphore, and not a pthread mutex.
There are process-shared mutexes and robust process-shared mutexes
that automatically unlock and notify the new owner on next acquire if
a process died while owning the mutex, possibly leaving the protected
data inconsistent. These are very reasonable tools to use, but they
don't work across the boundaries between different physical or logical
systems.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
