Re: [PATCH 00/10] [RFC] Simple IPC Mechanism
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Jan 13, 2021, 00:32 UTC
- Message-ID
- <968235ae-4b31-f06c-149a-c581e64b318b@jeffhostetler.com>
- In-Reply-To
- <xmqqo8htzoba.fsf@gitster.c.googlers.com>
On 1/12/21 7:13 PM, Junio C Hamano wrote:
Show 14 quoted lines
> Jeff Hostetler <git@jeffhostetler.com> 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\<unique-path>` 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.
Show 14 quoted lines
> >> 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. >