git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Behavior of core.sharedRepository on non-bare Repositories

From
JLJohn A. Leuenhagen <john@zlima12.com>
Date
Jan 17, 2022, 23:09 UTC
Message-ID
<20220117230827.c4s4kmejk675drf7@Zulu-1>
In-Reply-To
<YeXz0MYd8wduM9W+@camp.crustytoothpaste.net>
On Mon, Jan 17, 2022 at 10:55:12PM +0000, brian m. carlson wrote:
Show 13 quoted lines
> 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.

Previous: brian m. carlsonNext: Junio C Hamano
Message 3 of 5 in “Behavior of core.sharedRepository on non-bare Repositories”
  1. John A. LeuenhagenJan 17, 2022
  2. brian m. carlsonJan 17, 2022
  3. John A. LeuenhagenJan 17, 2022
  4. Junio C HamanoJan 17, 2022
  5. Junio C HamanoJan 17, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.