{"thread":{"id":"60896","subject":"git gc changes ownerships of files linux","startedAt":"2024-02-10T19:52:49Z","lastAt":"2024-02-11T19:48:40Z","messageCount":8,"participants":["K_V","Torsten Bögershausen","brian m. carlson","Junio C Hamano","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"488372","messageId":"CABkRduQNdgdF8WhZadP5hyYvpEWgP_AE8=qzxNiRNA71bdJcYQ@mail.gmail.com","threadId":"60896","inReplyTo":null,"subject":"git gc changes ownerships of files linux","fromName":"K_V","fromEmail":"zinen2@gmail.com","sentAt":"2024-02-10T19:52:22Z","receivedAt":"2024-02-10T19:52:49Z","isPatch":false,"sender":{"key":"zinen2@gmail.com","avatar":null},"body":"Hi team git\n\nRunning 'git -C /srv/mssioncontrol/.git gc' on linux from a user which\nhas access to another users files will occasionally change the\nownership of the file 'packed-refs'. I believe git actually overwrites\nthe file with a new one at the end af the gc command. But details\nabout this is not writen in the help text. Could it be a bug?\n\nUse case: I'm using ansible to cleanup .git directories across\nmultible servers and this issue is starting to cause problems.\n\nMy solution is to make a variable containing the user and group id\nbefore running gc command and then reapply it afterwards:\ncurrent_owner_uid_gid=$(stat -c \"%u:%g\" /srv/mssioncontrol/.git)\ngit -C /srv/mssioncontrol/.git gc\nchown -R $current_owner_uid_gid \"/srv/mssioncontrol/.git\"\n\nDetails:\nDebian GNU/Linux 12 (bookworm)\ngit version 2.39.2\n\nBest:\nzinen\n"},{"id":"488393","messageId":"20240211151455.GA27103@tb-raspi4","threadId":"60896","inReplyTo":"CABkRduQNdgdF8WhZadP5hyYvpEWgP_AE8=qzxNiRNA71bdJcYQ@mail.gmail.com","subject":"Re: git gc changes ownerships of files linux","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-02-11T15:14:55Z","receivedAt":"2024-02-11T15:15:04Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sat, Feb 10, 2024 at 08:52:22PM +0100, K_V wrote:\n> Hi team git\n>\n> Running 'git -C /srv/mssioncontrol/.git gc' on linux from a user which\n> has access to another users files will occasionally change the\n> ownership of the file 'packed-refs'. I believe git actually overwrites\n> the file with a new one at the end af the gc command. But details\n> about this is not writen in the help text. Could it be a bug?\n>\n> Use case: I'm using ansible to cleanup .git directories across\n> multible servers and this issue is starting to cause problems.\n>\n> My solution is to make a variable containing the user and group id\n> before running gc command and then reapply it afterwards:\n> current_owner_uid_gid=$(stat -c \"%u:%g\" /srv/mssioncontrol/.git)\n> git -C /srv/mssioncontrol/.git gc\n> chown -R $current_owner_uid_gid \"/srv/mssioncontrol/.git\"\n>\n> Details:\n> Debian GNU/Linux 12 (bookworm)\n> git version 2.39.2\n\nThanks for reporting this -\nI think that you have a working workaround ?\n\nHowever, Git has a feature called \"shared repository\".\nYou need to define a (unix) group that is shared between\nyour user(s) and the ansible user.\n\nThe basic trick is to do\ngit config core.sharedRepository true\n\n(And then change the ownership of all files/directories to the new group)\n\nThere is a docu here, please search for core.sharedRepository\nhttps://git-scm.com/docs/git-config\n\nI wonder, which solution is easier to maintain ?\n\n>\n> Best:\n> zinen\n>\n"},{"id":"488394","messageId":"ZcjnuSAZiNHvA5h1@tapette.crustytoothpaste.net","threadId":"60896","inReplyTo":"20240211151455.GA27103@tb-raspi4","subject":"Re: git gc changes ownerships of files linux","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-02-11T15:28:57Z","receivedAt":"2024-02-11T15:29:05Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-02-11 at 15:14:55, Torsten Bögershausen wrote:\n> Thanks for reporting this -\n> I think that you have a working workaround ?\n> \n> However, Git has a feature called \"shared repository\".\n> You need to define a (unix) group that is shared between\n> your user(s) and the ansible user.\n> \n> The basic trick is to do\n> git config core.sharedRepository true\n> \n> (And then change the ownership of all files/directories to the new group)\n\nOn Linux, you also should set each directory to be setgid.  That's\nbecause by default, Linux uses the user's current group ID as the group\nto create new directories.  However, you'll want the group to be\ninherited from the parent directory, which is the behaviour when the\nparent directory is setgid.\n\nThis behaviour is the default on the BSDs, and no such configuration is\nrequired there.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"488395","messageId":"20240211154345.GA28699@tb-raspi4","threadId":"60896","inReplyTo":"ZcjnuSAZiNHvA5h1@tapette.crustytoothpaste.net","subject":"Re: git gc changes ownerships of files linux","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-02-11T15:43:45Z","receivedAt":"2024-02-11T15:44:04Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sun, Feb 11, 2024 at 03:28:57PM +0000, brian m. carlson wrote:\n> On 2024-02-11 at 15:14:55, Torsten Bögershausen wrote:\n> > Thanks for reporting this -\n> > I think that you have a working workaround ?\n> >\n> > However, Git has a feature called \"shared repository\".\n> > You need to define a (unix) group that is shared between\n> > your user(s) and the ansible user.\n> >\n> > The basic trick is to do\n> > git config core.sharedRepository true\n> >\n> > (And then change the ownership of all files/directories to the new group)\n>\n> On Linux, you also should set each directory to be setgid.  That's\n> because by default, Linux uses the user's current group ID as the group\n> to create new directories.  However, you'll want the group to be\n> inherited from the parent directory, which is the behaviour when the\n> parent directory is setgid.\n>\n> This behaviour is the default on the BSDs, and no such configuration is\n> required there.\nBriam, Hm, I wonder what this function (in path.c) does:\n\nint adjust_shared_perm(const char *path)\n\nAccording to my understanding, it was included into the Git codebase\nto work around the missing \"setgid\" feature in Linux (and probably cygwin).\nAnd then we have t/t1301-shared-repo.sh,\nso I think we are in a good shape: for all systems that have posix permissions.\nand do not overwrite them with facl or other features.\n\n\n"},{"id":"488397","messageId":"xmqqcyt39cju.fsf@gitster.g","threadId":"60896","inReplyTo":"20240211154345.GA28699@tb-raspi4","subject":"Re: git gc changes ownerships of files linux","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-11T16:43:33Z","receivedAt":"2024-02-11T16:43:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> Briam, Hm, I wonder what this function (in path.c) does:\n>\n> int adjust_shared_perm(const char *path)\n>\n> According to my understanding, it was included into the Git codebase\n> to work around the missing \"setgid\" feature in Linux (and probably cygwin).\n\nNo.  \"g+s on directory\" is required and depended upon for getting\nthe correct group ownership.  We do not do anything to chown(2) a\nfilesystem entry to force what group it is owned by there.\n\nWhat adjust_shared_perm() does is to counter what the screwed-up\numask settings the user may have causes.  If you are a member of a\ngroup and working in a directory owned by the group with other\nmembers, you want to make sure others in the group can access the\nfiles and the directories in the project.  Their umask should be\nloosened to at least 027 and preferrably to 007 to give group\nmembers the same access as you do.  Yet people do not loosen their\numask when starting work in such a group owned directory that is\nsupposed to be shared, as it would be extremely cumbersome to do\n[*].  These users end up creating files with overly tight permission\nbits, e.g. 0644 or 0700, and we go in with adjust_shared_perm() to\nfix these modes.\n\nYou definitely must set up your initial directory with g+s if you\nare usihng the group-writable shared directory model (which I would\nactually be surprised to see in 2020---is a shared machine with more\nthan one user-account still a thing???); adjust_shared_perm() will\nnot help you there.\n\n\n[Footnote]\n\n* Unless, of course, you use some sort of \"hook\" in the shell to\n  notice you switched to a certain directory and run command\n  there---some people achieve this by aliasing their \"cd\", \"pushd\",\n  and \"popd\".\n\n"},{"id":"488399","messageId":"20240211165941.GB28699@tb-raspi4","threadId":"60896","inReplyTo":"xmqqcyt39cju.fsf@gitster.g","subject":"Re: git gc changes ownerships of files linux","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-02-11T16:59:41Z","receivedAt":"2024-02-11T16:59:54Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sun, Feb 11, 2024 at 08:43:33AM -0800, Junio C Hamano wrote:\n> Torsten Bögershausen <tboegi@web.de> writes:\n>\n> > Briam, Hm, I wonder what this function (in path.c) does:\n> >\n> > int adjust_shared_perm(const char *path)\n> >\n> > According to my understanding, it was included into the Git codebase\n> > to work around the missing \"setgid\" feature in Linux (and probably cygwin).\n>\n> No.  \"g+s on directory\" is required and depended upon for getting\n> the correct group ownership.  We do not do anything to chown(2) a\n> filesystem entry to force what group it is owned by there.\n>\n> What adjust_shared_perm() does is to counter what the screwed-up\n> umask settings the user may have causes.  If you are a member of a\n> group and working in a directory owned by the group with other\n> members, you want to make sure others in the group can access the\n> files and the directories in the project.  Their umask should be\n> loosened to at least 027 and preferrably to 007 to give group\n> members the same access as you do.  Yet people do not loosen their\n> umask when starting work in such a group owned directory that is\n> supposed to be shared, as it would be extremely cumbersome to do\n> [*].  These users end up creating files with overly tight permission\n> bits, e.g. 0644 or 0700, and we go in with adjust_shared_perm() to\n> fix these modes.\n>\n> You definitely must set up your initial directory with g+s if you\n> are usihng the group-writable shared directory model (which I would\n> actually be surprised to see in 2020---is a shared machine with more\n> than one user-account still a thing???); adjust_shared_perm() will\n> not help you there.\n>\n\nOh - I learned something today and sorry for the noise.\n\n>\n> [Footnote]\n>\n> * Unless, of course, you use some sort of \"hook\" in the shell to\n>   notice you switched to a certain directory and run command\n>   there---some people achieve this by aliasing their \"cd\", \"pushd\",\n>   and \"popd\".\n>\n>\n"},{"id":"488415","messageId":"ZckbeJqdvIfY4YPu@tapette.crustytoothpaste.net","threadId":"60896","inReplyTo":"xmqqcyt39cju.fsf@gitster.g","subject":"Re: git gc changes ownerships of files linux","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-02-11T19:09:44Z","receivedAt":"2024-02-11T19:09:49Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-02-11 at 16:43:33, Junio C Hamano wrote:\n> You definitely must set up your initial directory with g+s if you\n> are usihng the group-writable shared directory model (which I would\n> actually be surprised to see in 2020---is a shared machine with more\n> than one user-account still a thing???); adjust_shared_perm() will\n> not help you there.\n\nI think it's relatively common to have shell hosts from which to log\ninto production machines, or to have shared hosts for students at\nuniversities, and I do know that shared web hosting is still quite\npopular (because it tends to be very economical and low maintenance for\nthe user).\n\nI don't know that shared repositories are really that common anymore,\nand I do usually recommend that people clone their own copies whenever\npossible, but I have seen posts on StackOverflow where people are in\nfact using a shared repository (possibly with multiple worktrees) on one\nsystem for various reasons.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"488417","messageId":"006101da5d23$436ff460$ca4fdd20$@nexbridge.com","threadId":"60896","inReplyTo":"ZckbeJqdvIfY4YPu@tapette.crustytoothpaste.net","subject":"RE: git gc changes ownerships of files linux","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-02-11T19:48:13Z","receivedAt":"2024-02-11T19:48:40Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, February 11, 2024 2:10 PM, brian m. carlson wrote:\n>On 2024-02-11 at 16:43:33, Junio C Hamano wrote:\n>> You definitely must set up your initial directory with g+s if you are\n>> usihng the group-writable shared directory model (which I would\n>> actually be surprised to see in 2020---is a shared machine with more\n>> than one user-account still a thing???); adjust_shared_perm() will not\n>> help you there.\n>\n>I think it's relatively common to have shell hosts from which to log into production\n>machines, or to have shared hosts for students at universities, and I do know that\n>shared web hosting is still quite popular (because it tends to be very economical and\n>low maintenance for the user).\n>\n>I don't know that shared repositories are really that common anymore, and I do\n>usually recommend that people clone their own copies whenever possible, but I\n>have seen posts on StackOverflow where people are in fact using a shared\n>repository (possibly with multiple worktrees) on one system for various reasons.\n\nIn my community, shared repositories are particularly common on the operations side of the fence. It is a balance between the need for one user id (generally does not log on) running the scripts, and the individual operations staff specifying them. I have developed (commercial) solutions to this that remove the need shared repositories in this circumstance, but up to now, I have seen them used. This comes into play when multiple people are manipulating web server content without a separate deployment mechanism.\n\n"}]}