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

From: Junio C Hamano <[email-masked]>
Date: Thu, 04 Mar 2021 12:34:54 -0800

Jeff King <[email-masked]> writes:

> The feature is definitely useful; I think I did 1eb10f4091 (unix-socket:
> handle long socket pathnames, 2012-01-09) in response to a real problem.
>
> Certainly callers could handle the error themselves. The reason I pushed
> it down into the socket code was to avoid having to implement in
> multiple callers. There are only two, but we'd have needed it in both
> sides (credential-cache--daemon as the listener, and credential-cache as
> the client).
>
> Ironically, the listening side now does a permanent chdir() to the
> socket directory anyway, since 6e61449051 (credential-cache--daemon:
> change to the socket dir on startup, 2016-02-23). So we could just do
> that first, and then feed the basename to the socket code.
>
> The client side would still need to handle it, though. It could probably
> also chdir to the socket directory without any real downside (once
> started, I don't think the helper program needs to access the filesystem
> at all outside of the socket).
>
> So I dunno. I'd be OK to just rip the feature out in favor of doing
> those chdir()s. But that seems like a non-zero amount of work versus
> leaving, and the existing code has the benefit that if another caller
> shows up, it could benefit from the feature.

I am OK to keep the series as-is, and leave it to a possible future
work to remove the need for chdir even for long paths and not having
to return an error with ENAMETOOLONG; when such an update happens,
the "fail if need to chdir" feature this patch is adding will become
a no-op.