From: Jeff Hostetler Date: Wed, 13 Jan 2021 00:32:38 GMT Subject: Re: [PATCH 00/10] [RFC] Simple IPC Mechanism Message-ID: <968235ae-4b31-f06c-149a-c581e64b318b@jeffhostetler.com> In-Reply-To: On 1/12/21 7:13 PM, Junio C Hamano wrote: > Jeff Hostetler writes: > >> On Windows a local named pipe is created by the server side. It rejects >> remote connections. I did not put an ACL, so it should inherit the >> system default which grants the user RW access (since the daemon is >> implicitly started by the first foreground client command that needs >> to talk to it.) Other users in the user's group and the anonymous >> user should have R but not W access to it, so they could not be able >> to connect. The name pipe is kept in the local Named Pipe File System >> (NPFS) as `\\.\pipe\` so it is globally visible on the >> system, but I don't think it is a problem. > > It is not intuitively obvious why globalluy visible thing is OK to > me, but I'll take your word for it on stuff about Windows. Sorry, that's a quirk of Windows. Windows has a funky virtual drive where named pipes are stored -- kind of like a magic directory in /proc on Linux. All local named pipes have the "\\.\pipe\" path prefix. So they are globally visible as a side-effect of that "namespace" restriction. > >> 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. > > OK, yes, writability to .git would automatically mean that > everything is a fair game to those who can talk to the daemon, so > there is no new issue here, as long as the first process that > creates the socket is careful not to loosen the permission. > > Thanks. >