Re: [PATCH v4 09/12] unix-socket: disallow chdir() when creating unix domain sockets

From: Jeff Hostetler <git@jeffhostetler.com>
Date: Mar 5, 2021, 17:33 UTC
Message-ID: <449a73be-52e3-8363-b771-959f8114e3a0@jeffhostetler.com>
In-Reply-To: <CAPx1GvfXO9Xd+9Fqp-M13WUUNWVtemWm__O4N5WUk7=s4up1Gg@mail.gmail.com>

On 3/5/21 6:59 AM, Chris Torek wrote:

Show 25 quoted lines

>> On Fri, Mar 05, 2021 at 04:02:16AM -0500, Jeff King wrote:
>>
>>> I don't know offhand if this [bind in a child] trick actually works. ...
> 
> On Fri, Mar 5, 2021 at 1:29 AM Jeff King <peff@peff.net> wrote:
>> I was curious, but this does indeed work:
> [working example snipped]
> 
> Yes, it definitely works.  The bind() call, on a Unix domain socket,
> creates a file system entity linked to the underlying socket instance.
> The file descriptors, in whatever processes have them, provide
> read/write/send/recv/etc linkage to the underlying socket instance
> (and also a refcount or other GC protection: with the ability to
> send sockets over sockets, simple refcounts stop working and we
> need real GC in the kernel...).
> 
> Of course, once all the file descriptor references are gone, the
> socket (eventually, depending on GC) evaporates.  The file system
> entity does not count for keeping the underlying socket alive.  At
> this point the file system entity is "dead".  Unfortunately there's no
> way to test and clean out the dead entity atomically.  The whole
> thing is kind of a mess.
> 
> Chris
>

The original problem was that chdir() is not safe in a multi-threaded process because one thread calling chdir() will affect any concurrent file operations (open(), mkdir(), etc.) that use relative paths.

I think Adding a fork() at this layer would just create new types of problems. For example, if another thread was concurrently writing to a socket while we were setting up this new socket, we would suddenly have 1 thread in each process now writing to that socket and the receiver would get a mixture of output from both processes. Right?

Jeff