On Tue, Jan 12, 2021 at 06:25:20PM -0500, Jeff Hostetler wrote:
> On the Unix side, the socket is created inside the .git directory
> by the daemon. Potential clients would have to have access to the
> working directory and the .git directory to connect to the socket,
> so in normal circumstances they would be able to read everything in
> the WD anyway. So again, I don't think it is a problem.
Just thinking out loud, here are two potential issues with putting it in
.git that we may have to deal with later:
- fsmonitor is conceptually a read-only thing (i.e., it would speed up
"git status", etc). And not knowing much about how it will work, I'd
guess that is carried through (i.e., even though you may open the
socket R/W so that you can write requests and read them back, there
is no operation you can request that will overwrite data). But the
running user may not have write access to .git.
As long as we cleanly bail to the non-fsmonitor code paths, I don't
think it's the end of the world. Those read-only users just won't
get to use the speedup (and it may even be desirable). They may
complain, but it is open source so the onus is on them to improve
it. You will not have made anything worse. :)
- repositories may be on network filesystems that do not support unix
sockets.
So it would be nice if there was some way to specify an alternate path
to be used for the socket. Possibly one or both of:
- a config option to give a root path for sockets, where Git would
then canonicalize the $GIT_DIR name and use $root/$GIT_DIR for the
socket. That solves the problem for a given user once for all repos.
- a config option to say "use this path for the socket". This would be
per-repo, but is more flexible and possibly less confusing.
One final note: on some systems[1] the permissions on the socket file
itself are ignored. The safe way to protect it is to make sure the
permissions on the surrounding directory are what you want. See
credential-cache's init_socket_directory() for an example.
-Peff
[1] Sorry, I don't remember which systems. This is one of those random
bits of Unix lore I've carried around for 20 years, and it's
entirely possible it is simply obsolete at this point.
