On Wed, Jan 13 2021, Jeff King wrote: > 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. According to StackExchange lore this seems to have been the case with 4.2 BSD & maybe something obscure like HP/UX: https://unix.stackexchange.com/questions/83032/which-systems-do-not-honor-socket-read-write-permissions I'd say it's probably safe to ignore this as a concern for new features in git in general, and certainly for something like a thing intended for a watchman-like program which users are likely to only run on modern OS's.
