unix_stream_connect and socket address resolution

["John Ericson" <mail@johnericson.me>]

In [1] I observed what I considered some odd behavior in unix_stream_connect():

> I was hoping this was going to be a simple matter of factoring out the
> back half of `unix_stream_connect`. No such luck was had, because
> actually instead of `unix_stream_connect` looking up the socket from the
> VFS once, it does it repeatedly in the same loop that is used to deal
> with full listening queues.
> 
> (This behavior is rather surprising to me, because it would allow a
> deleted and recreated socket to be picked up on the next loop iteration.
> But, I don't want to make any UAPI-visible changes in this patch series,
> so I did not consider changing it.)

I had said I didn't want to consider changing this yet in my patch
series, but based on the feedback I received for a second version of
that patch series, I now actually think it is a good idea after all to
discuss this first, and see if it should be changed prior to my patch
series. (This discussion will inform what the code looks like before I
do my v2 patch series, and how big or small that patch series is.)

Here are two scenarios where the current behavior of
`unix_stream_connect` is surprising:

File system version:

1. server binds socket `/foo/bar`

2. clients fill up the accept queue, begin looping

3. `mv /foo /foo2; mkdir /foo`

4. another server binds `/foo/bar`

5. clients connect to the second server instead

The loop in question is within `unix_stream_connect` itself, not in
user code. I consider it very surprising that `/foo/bar` is looked up
multiple times during a single system call.

Abstract socket version:

1. server binds abstract socket `@foo`

2. clients fill up the accept queue, begin looping

3. server closes its socket (or exits), releasing the abstract name

4. another server binds `@foo`

5. clients connect to the second server instead

For abstract sockets we cannot play tricks with `mv`: the first server
does need to relinquish `@foo` itself. But still, the result is the same
where a different socket is resolved on the next loop iteration in
`unix_stream_connect`. I am not sure it is fair to call this a TOCTOU
issue exactly, but it feels very similar to one.

The more natural semantics in my view would be to first resolve the
address to a socket, and then loop holding that resolved socket
constant. With these semantics:

- In the `mv` case, the retrying clients continue to try connecting to
  the original socket, now at `/foo2/bar`.

- In the close case, the retrying clients fail, and do not connect to
  any new socket at the same path or abstract name.

What do you all think? Is this better? If so, is this a security fix
which can be made unconditionally, or, absent a real concrete attack
vector, is this a UAPI-breaking change which is automatically out of
scope, and would thus need an explicit opt-in mechanism?

Looking forward to feedback,

John

[1]: https://lore.kernel.org/all/20260703073948.2541875-3-John.Ericson@Obsidian.Systems/