Behavior of core.sharedRepository on non-bare Repositories

Behavior of core.sharedRepository on non-bare Repositories

[John A. Leuenhagen]

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.

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

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

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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[John A. Leuenhagen]

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.

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

[Junio C Hamano]

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

> 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.

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.

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

[Junio C Hamano]

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

> 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.

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.