{"thread":{"id":"53707","subject":"Git config command ignores explicitly set file permissions","startedAt":"2020-06-18T13:24:11Z","lastAt":"2020-06-18T21:37:46Z","messageCount":5,"participants":["Riddell, Matthew A","Junio C Hamano","Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"400058","messageId":"MN2PR02MB66232254F5F4BE27F21C441CD89B0@MN2PR02MB6623.namprd02.prod.outlook.com","threadId":"53707","inReplyTo":null,"subject":"Git config command ignores explicitly set file permissions","fromName":"Riddell, Matthew A","fromEmail":"mriddell@paychex.com","sentAt":"2020-06-18T13:13:57Z","receivedAt":"2020-06-18T13:24:11Z","isPatch":false,"sender":{"key":"mriddell@paychex.com","avatar":null},"body":"Hello,\n\nI noticed while working with Git that the file permissions on the gitconfig file is ignored and the parent folder permissions are used instead to update the file. \nAn example is as follows:\n\nBefore running git config ensure the user running the command is not able to edit the file but has read access to the file. Ensure the User has full access to the parent folder. \nAfter running any git config command the user previously without edit permissions on a file can now edit the config file.\n\nI documented the issue in more details in this ticket https://github.com/git-for-windows/git/issues/2686\n\nI originally found the issue while working in the windows version of git but @dscho noted that it is also an issue in the WSL version of git and believes it is caused by creating the .lock file which replaces the original file.\n@dscho also suggested I send out an email to this mailing list.\n\nLet me know if I can provide any more information\n\nThanks,\n\nMatthew Riddell\n\n----------------------------------------------------------------------\nThe information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.\n"},{"id":"400073","messageId":"xmqqsgesns22.fsf@gitster.c.googlers.com","threadId":"53707","inReplyTo":"MN2PR02MB66232254F5F4BE27F21C441CD89B0@MN2PR02MB6623.namprd02.prod.outlook.com","subject":"Re: Git config command ignores explicitly set file permissions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-18T18:32:21Z","receivedAt":"2020-06-18T18:32:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Riddell, Matthew A\" writes:\n\n> I noticed while working with Git that the file permissions on the\n> gitconfig file is ignored and the parent folder permissions are\n> used instead to update the file. An example is as follows:\n>\n> Before running git config ensure the user running the command is\n> not able to edit the file but has read access to the file. Ensure\n> the User has full access to the parent folder. After running any\n> git config command the user previously without edit permissions on\n> a file can now edit the config file.\n\nThat is pretty much how things are intended to work on a filesystem\nand is not limited to Git. Your arrangement, contrary to what you\nsaid, does not \"ensure the user running the command is not able to\nedit but has read access\".\n\n mkdir newdir\n chmod +rwx newdir\n >newdir/file\n chmod a-w newdir/file\n\nwould not forbid you from doing\n\n rm -f newdir/file\n ehco new >newdir/file\n\nIn other words, if you allow your user to write to a directory, you\ncannot forbid the user from creating and removing files in it.\n"},{"id":"400079","messageId":"022601d645af$45d0e640$d172b2c0$@nexbridge.com","threadId":"53707","inReplyTo":"xmqqsgesns22.fsf@gitster.c.googlers.com","subject":"RE: Git config command ignores explicitly set file permissions","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2020-06-18T20:30:08Z","receivedAt":"2020-06-18T20:30:27Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On June 18, 2020 2:32 PM, Junio C Hamano wrote:\n> \"Riddell, Matthew A\" writes:\n> > I noticed while working with Git that the file permissions on the\n> > gitconfig file is ignored and the parent folder permissions are used\n> > instead to update the file. An example is as follows:\n> >\n> > Before running git config ensure the user running the command is not\n> > able to edit the file but has read access to the file. Ensure the User\n> > has full access to the parent folder. After running any git config\n> > command the user previously without edit permissions on a file can now\n> > edit the config file.\n\nForgive me to asking, but is this an attempt at replicating what other VCS\nsystems do? ClearCase is an example where files are forced to read-only and\nif the user wants to modify it, then they have to ask nicely for a lock on\nthe file. The use of \"read only\" is a semi-guarantee that a user will not\nmodify code and interfere with other users. In git, the rules are quite\ndifferent, where modification resolution occurs later in the process.\n\n> That is pretty much how things are intended to work on a filesystem and is\n> not limited to Git. Your arrangement, contrary to what you said, does not\n> \"ensure the user running the command is not able to edit but has read\n> access\".\n> \n> mkdir newdir\n> chmod +rwx newdir\n> >newdir/file\n> chmod a-w newdir/file\n> \n> would not forbid you from doing\n> \n> rm -f newdir/file\n> ehco new >newdir/file\n> \n> In other words, if you allow your user to write to a directory, you cannot\n> forbid the user from creating and removing files in it.\n\nJust inquiring about this, as git operational decisions are fundamentally\ndifferent from older systems.\n\nRegards,\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"400091","messageId":"MN2PR02MB66237FBAE6695D80B1182BA5D89B0@MN2PR02MB6623.namprd02.prod.outlook.com","threadId":"53707","inReplyTo":"022601d645af$45d0e640$d172b2c0$@nexbridge.com","subject":"RE: Git config command ignores explicitly set file permissions","fromName":"Riddell, Matthew A","fromEmail":"mriddell@paychex.com","sentAt":"2020-06-18T20:57:27Z","receivedAt":"2020-06-18T21:07:46Z","isPatch":false,"sender":{"key":"mriddell@paychex.com","avatar":null},"body":"> \"Riddell, Matthew A\" writes:\n> > I noticed while working with Git that the file permissions on the \n> > gitconfig file is ignored and the parent folder permissions are used \n> > instead to update the file. An example is as follows:\n> >\n> > Before running git config ensure the user running the command is not \n> > able to edit the file but has read access to the file. Ensure the \n> > User has full access to the parent folder. After running any git \n> > config command the user previously without edit permissions on a \n> > file can now edit the config file.\n\n>>Forgive me to asking, but is this an attempt at replicating what other VCS systems do? ClearCase is an example where files are forced to read-only and if the user wants to modify it, then they have to ask nicely for a >>lock on the file. The use of \"read only\" is a semi-guarantee that a user will not modify code and interfere with other users. In git, the rules are quite different, where modification resolution occurs later in the process.\n\nWe have had problems in our continuous integration environment with builds modifying the global configuration of tools. I came across this issue trying to lock down our git global configuration for the local user running our builds. The workaround I found is creating a symlink from the user home directory to another folder (which has read only permissions) which contains the actual gitconfig file.\n\n-----Original Message-----\nFrom: Randall S. Becker \nSent: Thursday, June 18, 2020 4:30 PM\nTo: 'Junio C Hamano' ; Riddell, Matthew A \nCc: git@vger.kernel.org\nSubject: RE: Git config command ignores explicitly set file permissions\n\n\nWarning: This email is from outside the company. Be careful clicking links or attachments.\n\nOn June 18, 2020 2:32 PM, Junio C Hamano wrote:\n> \"Riddell, Matthew A\" writes:\n> > I noticed while working with Git that the file permissions on the \n> > gitconfig file is ignored and the parent folder permissions are used \n> > instead to update the file. An example is as follows:\n> >\n> > Before running git config ensure the user running the command is not \n> > able to edit the file but has read access to the file. Ensure the \n> > User has full access to the parent folder. After running any git \n> > config command the user previously without edit permissions on a \n> > file can now edit the config file.\n\nForgive me to asking, but is this an attempt at replicating what other VCS systems do? ClearCase is an example where files are forced to read-only and if the user wants to modify it, then they have to ask nicely for a lock on the file. The use of \"read only\" is a semi-guarantee that a user will not modify code and interfere with other users. In git, the rules are quite different, where modification resolution occurs later in the process.\n\n> That is pretty much how things are intended to work on a filesystem \n> and is not limited to Git. Your arrangement, contrary to what you \n> said, does not \"ensure the user running the command is not able to \n> edit but has read access\".\n> \n> mkdir newdir\n> chmod +rwx newdir\n> >newdir/file\n> chmod a-w newdir/file\n> \n> would not forbid you from doing\n> \n> rm -f newdir/file\n> ehco new >newdir/file\n> \n> In other words, if you allow your user to write to a directory, you \n> cannot forbid the user from creating and removing files in it.\n\nJust inquiring about this, as git operational decisions are fundamentally different from older systems.\n\nRegards,\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000 UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n----------------------------------------------------------------------\nThe information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.\n"},{"id":"400092","messageId":"023601d645b8$b06f46f0$114dd4d0$@nexbridge.com","threadId":"53707","inReplyTo":"MN2PR02MB66237FBAE6695D80B1182BA5D89B0@MN2PR02MB6623.namprd02.prod.outlook.com","subject":"RE: Git config command ignores explicitly set file permissions","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2020-06-18T21:37:33Z","receivedAt":"2020-06-18T21:37:46Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On June 18, 2020 4:57 PM, Matthew wrote:\n> > \"Riddell, Matthew A\" writes:\n> > > I noticed while working with Git that the file permissions on the\n> > > gitconfig file is ignored and the parent folder permissions are used\n> > > instead to update the file. An example is as follows:\n> > >\n> > > Before running git config ensure the user running the command is not\n> > > able to edit the file but has read access to the file. Ensure the\n> > > User has full access to the parent folder. After running any git\n> > > config command the user previously without edit permissions on a\n> > > file can now edit the config file.\n> \n> >>Forgive me to asking, but is this an attempt at replicating what other\nVCS\n> systems do? ClearCase is an example where files are forced to read-only\nand\n> if the user wants to modify it, then they have to ask nicely for a >>lock\non the\n> file. The use of \"read only\" is a semi-guarantee that a user will not\nmodify\n> code and interfere with other users. In git, the rules are quite\ndifferent,\n> where modification resolution occurs later in the process.\n> \n> We have had problems in our continuous integration environment with builds\n> modifying the global configuration of tools. I came across this issue\ntrying to\n> lock down our git global configuration for the local user running our\nbuilds.\n> The workaround I found is creating a symlink from the user home directory\n> to another folder (which has read only permissions) which contains the\n> actual gitconfig file.\n\nAs a suggestion, you might want to add a git status -uno --porcelain to key\nparts of your scripts to find the conditions where that is occurring and\nfail the job if the output is not empty. CI tools and applications should\nnot change configurations unexpectedly and that would be a pipeline stage\nfailure - in my books anyway.\n\n"}]}