RE: Git config command ignores explicitly set file permissions

["Riddell, Matthew A" <mriddell@paychex.com>]

> "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > I 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.  An example is as follows:
> >
> > Before 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.  After running any git 
> > config command the user previously without edit permissions on a 
> > file can now edit the config file.

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

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

-----Original Message-----
From: Randall S. Becker <rsbecker@nexbridge.com> 
Sent: Thursday, June 18, 2020 4:30 PM
To: 'Junio C Hamano' <gitster@pobox.com>; Riddell, Matthew A <mriddell@paychex.com>
Cc: git@vger.kernel.org
Subject: RE: Git config command ignores explicitly set file permissions


Warning: This email is from outside the company. Be careful clicking links or attachments.

On June 18, 2020 2:32 PM, Junio C Hamano wrote:
> "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > I 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.  An example is as follows:
> >
> > Before 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.  After running any git 
> > config command the user previously without edit permissions on a 
> > file can now edit the config file.

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.

> That is pretty much how things are intended to work on a filesystem 
> and is not limited to Git.  Your arrangement, contrary to what you 
> said, does not "ensure the user running the command is not able to 
> edit but has read access".
> 
>     mkdir newdir
>     chmod +rwx newdir
>     >newdir/file
>     chmod a-w newdir/file
> 
> would not forbid you from doing
> 
>     rm -f newdir/file
>     ehco new >newdir/file
> 
> In other words, if you allow your user to write to a directory, you 
> cannot forbid the user from creating and removing files in it.

Just inquiring about this, as git operational decisions are fundamentally different from older systems.

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000  UNIX developer since approximately 421664400
-- In my real life, I talk too much.



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