From: Jeff Hostetler Date: Fri, 05 Mar 2021 17:33:11 GMT Subject: Re: [PATCH v4 09/12] unix-socket: disallow chdir() when creating unix domain sockets Message-ID: <449a73be-52e3-8363-b771-959f8114e3a0@jeffhostetler.com> In-Reply-To: On 3/5/21 6:59 AM, Chris Torek wrote: >> 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 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