[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8nMunOYKhT=J+MMrC7ULu0uLZzsE_ZhXpYPp5a8Ff3k5Q@mail.gmail.com>
Date: Mon, 10 Feb 2025 13:44:12 -0500
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, Florian Weimer <fweimer@...hat.com>
Subject: Re: pthread_mutex_t shared between processes with different
pid namespaces
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.
Jeff
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.
