{"thread":{"id":"57263","subject":"Behavior of core.sharedRepository on non-bare Repositories","startedAt":"2022-01-17T22:45:28Z","lastAt":"2022-01-17T23:12:16Z","messageCount":5,"participants":["John A. Leuenhagen","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"446388","messageId":"20220117223912.fwsydwpkwfbcdlcq@Zulu-1","threadId":"57263","inReplyTo":null,"subject":"Behavior of core.sharedRepository on non-bare Repositories","fromName":"John A. Leuenhagen","fromEmail":"john@zlima12.com","sentAt":"2022-01-17T22:39:12Z","receivedAt":"2022-01-17T22:45:28Z","isPatch":false,"sender":{"key":"john@zlima12.com","avatar":null},"body":"I've been trying to work with the core.sharedRepository option today.\n\nBased on the wording in the man page, I was under the impression that\nthis would affect all files in any type of repository (bare or not), but\nit seems as though this is not the case. It affects bare repositories as\none would expect, but it only affects the .git directory on non-bare\nrepositories. The working tree is not affected by the option at all.\n\nI doubt that I'm the first person to encounter this issue, and I'm not\nsure why this behavior would be desirable. If for some reason it is\ndiscouraged to share a working tree between users in a group, I don't\nbelieve this option should affect non-bare repositories at all; there\nshould be a warning about any dangers associated with this kind of\nsetup instead.\n\nHowever, if we'd like to support this kind of thing, I believe that\nsimply applying the same permissions to files and directories in the\nworking tree would suit the language already used to describe the\nfeature. I could make a patch for this if people agree that it makes\nsense.\n"},{"id":"446389","messageId":"YeXz0MYd8wduM9W+@camp.crustytoothpaste.net","threadId":"57263","inReplyTo":"20220117223912.fwsydwpkwfbcdlcq@Zulu-1","subject":"Re: Behavior of core.sharedRepository on non-bare Repositories","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-01-17T22:55:12Z","receivedAt":"2022-01-17T22:55:16Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-01-17 at 22:39:12, John A. Leuenhagen wrote:\n> I've been trying to work with the core.sharedRepository option today.\n> \n> Based on the wording in the man page, I was under the impression that\n> this would affect all files in any type of repository (bare or not), but\n> it seems as though this is not the case. It affects bare repositories as\n> one would expect, but it only affects the .git directory on non-bare\n> repositories. The working tree is not affected by the option at all.\n> \n> I doubt that I'm the first person to encounter this issue, and I'm not\n> sure why this behavior would be desirable. If for some reason it is\n> discouraged to share a working tree between users in a group, I don't\n> believe this option should affect non-bare repositories at all; there\n> should be a warning about any dangers associated with this kind of\n> setup instead.\n\nI can't speak to how this feature is supposed to work on the working\ntree, but it is generally the case that users should not share a working\ntree. Any user who can modify the configuration can cause arbitrary code\nto be executed by every other user of the repository when they run\nalmost any Git command.\n\nThe only safe thing to do with an untrusted repository is perform a\nclone or fetch from it.\n\nIt may be in your case that all the users are trusted (e.g., all system\nadministrators), but in general it's strongly recommended that users not\nshare a working tree.  There'll be an entry in the FAQ describing this\nin the future.\n\nThat doesn't mean that this feature couldn't be extended to handle the\nworking tree, but I did want to provide some context on why working\ntrees aren't intended to be shared.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"446390","messageId":"xmqqo84at131.fsf@gitster.g","threadId":"57263","inReplyTo":"20220117223912.fwsydwpkwfbcdlcq@Zulu-1","subject":"Re: Behavior of core.sharedRepository on non-bare Repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-01-17T23:05:38Z","receivedAt":"2022-01-17T23:05:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"John A. Leuenhagen\" <john@zlima12.com> writes:\n\n> Based on the wording in the man page, I was under the impression that\n> this would affect all files in any type of repository (bare or not), but\n> it seems as though this is not the case. It affects bare repositories as\n> one would expect, but it only affects the .git directory on non-bare\n> repositories. The working tree is not affected by the option at all.\n\nThis behaviour, as far as I know, dates back way before \"git\nworktree add\" was invented.  Such an arrangement to share the object\nstore and refs (i.e. contents of .git/) among multiple worktrees\nwere already available via contrib/workdir/ even back then.\n\nThe motivation behind the current design may be that sharing a\nworking tree between two people to allow overwriting each other's\nchange in an uncontrolled way with their editors is a total disaster\nand nobody would consider doing such a nonsensical arrangement.  It\nmay be why we do not loosen the permission of working tree files\nbeyond what your umask does.\n\nBut allowing write access to the same repository from multiple\nworking trees were considered worth supporting.  More importantly,\nthe repository data access by git is not uncontrolled---there are\nprotections with lockfiles to avoid overwriting others' changes.\n\nIf multiple people must write into the same repository and the same\nworking tree, the umask(1) command is your friend.  Add these users\nto the same single group, have the repository and working tree files\nowned by that group, and make sure these users have umask no\nstricter than 007.\n\n"},{"id":"446391","messageId":"20220117230827.c4s4kmejk675drf7@Zulu-1","threadId":"57263","inReplyTo":"YeXz0MYd8wduM9W+@camp.crustytoothpaste.net","subject":"Re: Behavior of core.sharedRepository on non-bare Repositories","fromName":"John A. Leuenhagen","fromEmail":"john@zlima12.com","sentAt":"2022-01-17T23:09:15Z","receivedAt":"2022-01-17T23:09:20Z","isPatch":false,"sender":{"key":"john@zlima12.com","avatar":null},"body":"On Mon, Jan 17, 2022 at 10:55:12PM +0000, brian m. carlson wrote:\n> I can't speak to how this feature is supposed to work on the working\n> tree, but it is generally the case that users should not share a working\n> tree. Any user who can modify the configuration can cause arbitrary code\n> to be executed by every other user of the repository when they run\n> almost any Git command.\n> \n> The only safe thing to do with an untrusted repository is perform a\n> clone or fetch from it.\n> \n> It may be in your case that all the users are trusted (e.g., all system\n> administrators), but in general it's strongly recommended that users not\n> share a working tree.  There'll be an entry in the FAQ describing this\n> in the future.\n\nAlright, there should definitely be warnings about this then, I'm glad\nsomething will be added to the FAQ at least.\n\nIn my case, I wanted to have a user for the purpose of compiling some\nprojects. This user would be very unpriviliged, so that the build system\n(whether through misconfiguration or malice) couldn't do much harm.\n\nI intended to have a group that my own user and this unpriviliged user\nwould be in. All files and directories in the working tree would be\nowned by this group, and should be group-writable. This way, I could\nmake edits to source files, but the unpriviliged user could also do what\nit needed to while building the project.\n\n> That doesn't mean that this feature couldn't be extended to handle the\n> working tree, but I did want to provide some context on why working\n> trees aren't intended to be shared.\n\nOf course, thanks for the input. Considering the dangers you mentioned,\nperhaps this functionality is better off in a completely separate\noption. Or at the least, the description of the feature should be very\ndescriptive in all of this.\n"},{"id":"446392","messageId":"xmqqk0eyt0s5.fsf@gitster.g","threadId":"57263","inReplyTo":"xmqqo84at131.fsf@gitster.g","subject":"Re: Behavior of core.sharedRepository on non-bare Repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-01-17T23:12:10Z","receivedAt":"2022-01-17T23:12:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> But allowing write access to the same repository from multiple\n> working trees were considered worth supporting.  More importantly,\n> the repository data access by git is not uncontrolled---there are\n> protections with lockfiles to avoid overwriting others' changes.\n\nIOW, the expected set-up is for a repository (bare or non-bare) is\nmarked as shared, owned by the group, and each user who wants to\nwork locally on that project sharing the repository would belong to\nthe group.  Each user has a worktree added to the repository (via\n\"git worktree add\") and it is OK (and may even be encouraged) to\nhave their umask stricter than 022 to prevent other users in the\nsame group from mucking with the worktree files.  Since Git sets\nthe permission bits of these shared repository files to allow access\nby group members, looser than what umask(1) gives as needed, users\ncan share the repository contents without giving too loose an access\nto the worktree files.\n"}]}