On Mon, Jan 17, 2022 at 10:55:12PM +0000, brian m. carlson wrote: > I can't speak to how this feature is supposed to work on the working > tree, but it is generally the case that users should not share a working > tree. Any user who can modify the configuration can cause arbitrary code > to be executed by every other user of the repository when they run > almost any Git command. > > The only safe thing to do with an untrusted repository is perform a > clone or fetch from it. > > It may be in your case that all the users are trusted (e.g., all system > administrators), but in general it's strongly recommended that users not > share a working tree. There'll be an entry in the FAQ describing this > in the future. Alright, there should definitely be warnings about this then, I'm glad something will be added to the FAQ at least. In my case, I wanted to have a user for the purpose of compiling some projects. This user would be very unpriviliged, so that the build system (whether through misconfiguration or malice) couldn't do much harm. I intended to have a group that my own user and this unpriviliged user would be in. All files and directories in the working tree would be owned by this group, and should be group-writable. This way, I could make edits to source files, but the unpriviliged user could also do what it needed to while building the project. > That doesn't mean that this feature couldn't be extended to handle the > working tree, but I did want to provide some context on why working > trees aren't intended to be shared. Of course, thanks for the input. Considering the dangers you mentioned, perhaps this functionality is better off in a completely separate option. Or at the least, the description of the feature should be very descriptive in all of this.
