Behavior of core.sharedRepository on non-bare Repositories

I've been trying to work with the core.sharedRepository option today.

Based on the wording in the man page, I was under the impression that this would affect all files in any type of repository (bare or not), but it seems as though this is not the case. It affects bare repositories as one would expect, but it only affects the .git directory on non-bare repositories. The working tree is not affected by the option at all.

I doubt that I'm the first person to encounter this issue, and I'm not sure why this behavior would be desirable. If for some reason it is discouraged to share a working tree between users in a group, I don't believe this option should affect non-bare repositories at all; there should be a warning about any dangers associated with this kind of setup instead.

However, if we'd like to support this kind of thing, I believe that simply applying the same permissions to files and directories in the working tree would suit the language already used to describe the feature. I could make a patch for this if people agree that it makes sense.

On 2022-01-17 at 22:39:12, John A. Leuenhagen 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.

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.

On Mon, Jan 17, 2022 at 10:55:12PM +0000, brian m. carlson wrote:

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.

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.

"John A. Leuenhagen" <john@zlima12.com> writes:

This behaviour, as far as I know, dates back way before "git worktree add" was invented. Such an arrangement to share the object store and refs (i.e. contents of .git/) among multiple worktrees were already available via contrib/workdir/ even back then.

The motivation behind the current design may be that sharing a working tree between two people to allow overwriting each other's change in an uncontrolled way with their editors is a total disaster and nobody would consider doing such a nonsensical arrangement. It may be why we do not loosen the permission of working tree files beyond what your umask does.

But allowing write access to the same repository from multiple working trees were considered worth supporting. More importantly, the repository data access by git is not uncontrolled---there are protections with lockfiles to avoid overwriting others' changes.

If multiple people must write into the same repository and the same working tree, the umask(1) command is your friend. Add these users to the same single group, have the repository and working tree files owned by that group, and make sure these users have umask no stricter than 007.

Junio C Hamano <gitster@pobox.com> writes:

IOW, the expected set-up is for a repository (bare or non-bare) is marked as shared, owned by the group, and each user who wants to work locally on that project sharing the repository would belong to the group. Each user has a worktree added to the repository (via "git worktree add") and it is OK (and may even be encouraged) to have their umask stricter than 022 to prevent other users in the same group from mucking with the worktree files. Since Git sets the permission bits of these shared repository files to allow access by group members, looser than what umask(1) gives as needed, users can share the repository contents without giving too loose an access to the worktree files.