[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2bdf83642ba8f5400a6088fd45044fc90ac95339.camel@gmail.com>
Date: Mon, 10 Feb 2025 17:12:52 +0100
From: Daniele Personal <d.dario76@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: Florian Weimer <fweimer@...hat.com>, musl@...ts.openwall.com
Subject: Re: pthread_mutex_t shared between processes with different
pid namespaces
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.
> > >
> > > Rich
> > >
> >
> > 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).
>
> Rich
>
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?
Daniele.
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.
